Sales tax that survives an audit.
The tax on each sale and the tax in the ledger are the same number, because they come from the same engine — recorded once, hash-chained, in both the order currency and your base currency.
Extracted from INV-88213.pdf
| Account | Debit | Credit |
|---|---|---|
| 6300 Office equipmentNet of recoverable VAT | £2,000.00 | |
| 2201 VAT recoverableStandard rate, 20% | £400.00 | |
| 2100 Accounts payableDue 30 days | £2,400.00 | |
| Totals | £2,400.00 | £2,400.00 |
Nothing posts until an accountant approves it. The entry stays at needs-review until then.
The problem is never the rate. It is the reconciliation.
Getting a rate approximately right is easy. Proving twelve months later that the amount collected, the amount recorded and the amount remitted are the same amount is the part that fails.
Every order is a different jurisdiction
State and local sales tax, EU VAT, GST — different bases, different rounding, different rules about what shipping is. The same product is three different calculations depending on where it lands.
Reverse charge either applies or it does not
Cross-border B2B in the EU shifts the liability to the buyer, and getting it wrong is wrong in both directions — charging when you should not, or not charging when you should.
Nexus thresholds move underneath you
Economic nexus is a running total you crossed three weeks ago without noticing. By the time it shows up, the under-collected orders have already shipped.
Exemption certificates live in a drawer
A customer is exempt, someone knows about it, and nothing in the system does. The certificate exists but it is not attached to anything the system can read.
Refunds break the arithmetic
A partial refund has to prorate the tax across the original lines. Do it approximately and the ledger stops tying out to the orders, one refund at a time.
The storefront and the books disagree
Two systems computing tax separately will diverge. Not dramatically — by rounding, by timing, by currency conversion — which is worse, because it takes a full reconciliation to find.
One engine, two places, the same number.
The sales calculation and the ledger are not two implementations that agree most of the time. They are one calculation, recorded once, with the source order referenced from the entry it produced.
Indirect tax with the categories that exist
Standard, reduced, zero-rated and exempt; registration thresholds; reverse charge for cross-border B2B including intra-EU and imports; US state and local. Exact decimal arithmetic throughout.
Commerce and indirect taxTax-ID validation across 100+ national schemes
VAT numbers, GSTIN, EIN, ABN, RFC, CNPJ and more, with checksum validation rather than a format regex. This is a dimension where parity with the established providers genuinely exists, so it is stated as parity rather than as an advantage.
More than 100 national tax-ID schemes validated.
Nexus rules with point-in-time snapshots
Economic and physical nexus evaluated as rules, and snapshotted — so “was I registered when this order shipped” has an answer rather than a reconstruction.
Exemption certificates matched to the customer
Matched by customer, email or certificate, scopable by country and state, with the certificate itself stored against the match. EU reverse charge applies automatically when a customer holds a tax ID in a different EU country from the active registration.
Refund tax proration that ties out
Refunds carry prorated tax-refund metadata plus the original line-level tax detail, so the reconciliation has both the derived figure and what it was derived from.
Sales to ledger, recorded once and chained
A paid order is split into revenue, tax and shipping and posted once as a ledger entry, so a re-run never duplicates it. Entries are hash-chained per tenant with a back-reference to the source order.
Ledger entries are hash-chained per tenant, and a command validates the whole chain.
What happens between the sale and the books.
Six steps, and the point of the sequence is that the number computed at step two is the number that reaches step six. Nothing recomputes it on the way.
- 01
Identify the transaction
Place of supply, customer type, and whether a valid tax ID in another EU member state shifts this into reverse charge. Tax IDs are checksum-validated, not pattern-matched.
- 02
Calculate the tax
Configured region rates with a law-as-of date, in exact decimal, with the exemption and nexus rules applied. Not a live rate feed — the page says so on the coverage side too.
- 03
Issue the invoice
One tax invoice per order with both tax IDs, the currency, an exchange-rate snapshot, line items, the tax records, a checksum and a signed download reference.
- 04
Post to the ledger
On payment the order is split into revenue net of discounts, tax and shipping, in both the order currency and your base currency, and written once as a ledger entry.
- 05
Handle the refund
Tax is prorated across the original lines and the line-level detail travels with it, so a partial refund leaves the reconciliation intact rather than approximately intact.
- 06
Reconcile and detect
A nightly scan cross-references invoices, orders and refunds against the tax revenue ledger for missing payments, missing invoices, amount mismatches, duplicate invoices and unexpected refunds — five anomaly types, deduplicated by fingerprint.
Identify the transaction
A determination: who charges, at what rate, on what base — with the registration and the certificate that decided it recorded against the order.
Step 1 of 6 — Identify the transaction
The questions that come after the sale.
An audit is not about whether your rates were right on the day. It is about whether you can show what you charged, what you recorded and what you remitted, and demonstrate they are the same.
The ledger is tamper-evident
Entries are hash-chained per tenant — previous hash into entry hash — with a back-reference to the source order, and a validation check covers the whole chain. Changing one historical entry invalidates everything after it.
Ledger entries are hash-chained per tenant, and a command validates the whole chain.A re-run cannot double-count
Each order is posted once, so replaying a sync after an incident produces the same ledger rather than a second copy of a week's revenue.
Both currencies, with the rate that was used
Orders persist their base currency, exchange rate, provider and as-of date. A conversion done last March can be checked against the rate that was actually applied, not against today's.
Five anomaly types, checked nightly
Missing payment, missing invoice, amount mismatch, duplicate invoice and unexpected refund — each with severity, expected-versus-actual amounts and a dedupe fingerprint. A finding a human has resolved is never silently reopened.
5 ledger anomaly types detected.
The three that decide it.
Switching, missing rules and live rates. The questions where most answers get vague, answered specifically here.
Run a week of real orders through it.
Point it at last week's orders, including the refunds and the cross-border ones, and compare what comes out against what you charged. That comparison is the whole evaluation.
Decision support, not tax advice. A professional reviews before anything is filed.