UK B2B VAT compliance requires a consistent VAT registration number across ecommerce and Sage. Mismatch equals reverse-charge accounting error risk.
At a glance
The count of B2B customers whose VAT registration number recorded in the ecommerce platform does not match the VAT number held in the Sage customer master. Every mismatch is a customer where the system cannot reliably decide the correct VAT treatment, which under UK Making Tax Digital and EU cross-border reverse-charge rules is a compliance exposure, not a cosmetic data difference. The card exists because the VAT number is the single field that drives whether you charge standard-rate VAT, zero-rate, or apply the reverse charge, and disagreement between your sales surface and your book of record means the decision is being made on bad data.
Calculation
Calculated automatically by comparing the VAT registration number on matched B2B customers across your connected ecommerce platform and the Sage customer master. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK B2B merchant on Sage Intacct (single entity, GBP, UK VAT-registered, MTD-compliant) selling through a BigCommerce B2B portal and an Adobe Commerce wholesale store, with a meaningful slice of EU trade. Snapshot 14 Apr 26, evaluating customers active in the last 30 days. The card reads 7 mismatches, above the zero alert line. The finance lead opens the drill and splits by mismatch type.
Five things to notice:
- All 7 are compliance exposure, but the 3 EU reverse-charge cases are the ones that cost real money if they ship wrong. When an EU business customer supplies a valid VAT number, the UK supplier zero-rates and the customer accounts for VAT under the reverse charge. If the number is blank in Sage, the invoice cannot be reverse-charged and the system either charges UK VAT in error (which the customer will dispute and reclaim, creating a credit-note cycle) or stalls. The fix is to sync the captured number into the Sage master before the invoice batch runs, which is why the 30-day window matters: it catches the mismatch while the invoice is still pending.
- The blank-in-ecom, present-in-Sage cohort is the silent one because the checkout already made the wrong decision. Two existing customers ordered without re-entering their VAT number, so the storefront treated them as if they had none and may have charged standard VAT at checkout. Sage knows the correct number and would reverse-charge, creating a disagreement between what the customer was charged and what should be invoiced. This produces a reconciliation break and usually a credit note. The card surfaces it before close so finance can correct the invoice rather than discover the mismatch when the customer queries it.
- The single digit-difference case means one of the two numbers is invalid, and you must establish which. A transposed or mistyped VAT number will fail validation against the relevant authority (HMRC for GB numbers, VIES for EU numbers). The correct number is whichever validates; the card does not assume the Sage side is right, because the error can be on either system. The fix is a validation check, then correct the wrong side, then resync. Shipping against an invalid VAT number is a clear MTD exposure.
- The prefix-only case is usually a normalisation gap, not a true mismatch, and it should be the easiest to close. Same digits, different country prefix (GB123456789 vs 123456789) is a formatting difference that the card’s normalisation should already harmonise. If a prefix-only difference still surfaces, it points to a field-map normalisation rule that needs tuning rather than a customer-data correction. Fixing the rule clears this whole subset and prevents future false positives.
- This card sits directly upstream of the VAT return, which is why a B2B merchant usually runs it at zero tolerance. A mismatch that is not resolved becomes a revenue line with the wrong VAT code, which flows into Revenue Lines Missing VAT Code (MTD) and ultimately into Current VAT Return Status (MTD). HMRC penalises careless errors in MTD submissions. The cross-platform point is that the storefront captures the VAT number at checkout and Sage holds it for accounting, and only the join between them reveals when the two disagree. Neither system alone can flag the mismatch, because each trusts its own copy.
Sibling cards merchants should reference together
Reconciling against Sage
Where to look in Sage Intacct: The native Sage Intacct views to run side by side with this card:Accounts Receivable → Customers, the VAT registration field on each customer record (often a standard or custom field depending on the localisation pack) Reports → Accounts Receivable → Customer List with the VAT registration column exposed, exported and compared against the ecommerce customer export by account reference Tax / VAT configuration (the tax schedules and reverse-charge rules that consume the VAT number to decide treatment) Interactive Custom Report (ICR) on the Customer data source listingThe reconciliation discipline is normalisation. A manual comparison that does not strip whitespace, harmonise case, and handle country prefixes will report formatting differences as mismatches and overstate the count. The card normalises first, so it reports only substantive disagreements. Agree the normalisation rules before comparing. Common reconciliation pitfalls:CustomerID,CustomerName, account reference, and the VAT registration field, joined against the storefront’s B2B customer export Order Entry → Sales Orders for the affected customers, to see which open orders are about to invoice with the wrong VAT treatment
- Formatting vs substance. GB123456789, GB 123 4567 89, and gb123456789 are the same number. A manual comparison that compares raw strings finds mismatches the card correctly ignores.
- Which system is authoritative? The card does not assume Sage is right. For a digit-difference mismatch, the correct number is the one that validates against HMRC or VIES. Resolve by validation, not by trusting one side.
- Reverse-charge configuration. A correctly matched VAT number can still be mis-treated if the Sage tax schedule or reverse-charge rule is misconfigured. This card validates the number; it does not validate the tax rule. A clean count here does not guarantee correct VAT treatment if the schedule is wrong.
Cross-connector reconciliation:
The cross-platform high-leverage finding is that the VAT registration number lives in two places, the storefront where it is captured at checkout and Sage where it drives the accounting, and the two copies drift the moment a customer reorders without re-entering it, edits it in one system, or is created by a sync that does not carry the field. Neither system can see the disagreement because each trusts its own copy. Only the join exposes it, and exposing it before the invoice batch runs is the difference between a one-field correction and a credit-note cycle with a disputing customer and a contaminated VAT return. For a UK B2B merchant this is one of the highest-value joins Vortex IQ offers, and it is usually where the Implementation Partner makes the compliance case to finance.