B2B Customers with VAT Number Mismatch (ecom vs Sage), Sage

Card class: Hero • Category: Ecommerce Platform

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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-channel 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 listing 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

The 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:

• 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.

Why our number may legitimately differ from a manual VAT-number comparison: Cross-connector reconciliation: The cross-channel 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.

​

Known limitations / merchant FAQs

Does this card validate the VAT number against HMRC or VIES? The card normalises and compares the two stored numbers and can flag which side fails validation against HMRC (for GB numbers) or VIES (for EU numbers) where that check is enabled. Its primary job is to surface disagreement between systems; the validation check then tells you which side to correct. A number that validates on neither side is a data-entry error on both. Why do I sometimes see a mismatch that is just formatting? You should not, because the card normalises whitespace, case, and country prefix before comparing. If a pure-formatting difference still surfaces, it means a normalisation rule in the field map needs tuning, usually around country-prefix handling. Fixing the rule clears the whole prefix-only subset. Which system is authoritative, ecom or Sage? Neither by default. For a digit-difference mismatch, the authoritative number is the one that validates against the tax authority, which can be on either side. The card does not assume Sage is correct, because the error frequently originates at checkout. Resolve by validation, then correct the wrong side and resync. A customer has no VAT number at all, is that a mismatch? If both systems agree the number is blank, that is not a mismatch; it is a DTC or non-registered customer out of scope. A mismatch is present-vs-absent (one has it, one does not) or two genuinely different numbers. The blank-vs-blank case is filtered out. Why is the alert usually set to zero? Because a single mismatch on a B2B customer is a potential VAT return error, and MTD penalises careless errors. Unlike a count metric where a few is tolerable, one wrong VAT number can mean one wrongly treated invoice that contaminates the return. Most UK VAT-registered B2B merchants run this at zero tolerance. How does reverse charge fit in? For UK and EU B2B cross-border supplies, a valid customer VAT number triggers reverse-charge treatment (the supplier zero-rates, the customer accounts for VAT). A mismatched or blank number means the system cannot apply the reverse charge correctly and may charge VAT in error or fail to. This is the single most common financial consequence of a mismatch. Does a clean count guarantee correct VAT treatment? No. This card validates that the number agrees and is valid. It does not validate the Sage tax schedule or reverse-charge rule that consumes the number. A correctly matched number can still be mis-treated if the tax configuration is wrong. Pair with Transaction Imbalances and the VAT return cards to catch configuration-level errors. How does multi-entity affect the comparison? The same trading partner can hold a different VAT registration in different jurisdictions, so the card compares per entity. A number that is correct for the UK entity and different (correctly) for the German entity is not a mismatch; the per-entity comparison handles this. A consolidated raw comparison would wrongly flag it. Where does Sage store the VAT number? Depending on the localisation pack, it may be a standard field or a custom field on the customer record. The field map must point at the field Sage actually uses. A common cause of every-customer-reads-mismatch is the field map pointing at a blank field; verify the mapping first. Implementation Partner role on this metric? The Partner usually owns the VAT field mapping, the normalisation rules, the reverse-charge tax schedules, and the customer-sync configuration. If this card reads high on first connect, the cause is almost always a field-map issue (wrong VAT field) or a normalisation gap (prefix handling), not a genuine data crisis. Bring the Partner in to confirm the field map and normalisation before treating the count as a data-cleanup backlog.

---

​

Tracked live in Vortex IQ Nerve Centre

B2B Customers with VAT Number Mismatch (ecom vs Sage) is one of hundreds of KPI pulses Vortex IQ tracks across Sage and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.