B2B customers where the ecommerce-stored VAT / Tax ID differs from the Fusion Party record. A reverse-charge and tax-compliance risk; the wrong tax registration number can invalidate VAT treatment on cross-border B2B invoices.
At a glance
The count of B2B customers whose tax registration number, the VAT number, GST number, or equivalent Tax ID, stored on the ecommerce platform does not match the value held on the corresponding Oracle Fusion Party record. This is a genuine compliance exposure, not a cosmetic data issue. An incorrect tax registration number can invalidate the reverse-charge mechanism on a cross-border B2B sale, force a retrospective VAT correction, and put a tax filing at risk. Any non-zero reading is worth a same-week investigation, which is why this is a Hero card.
| What it counts | The number of B2B customers where the tax registration number on the commerce platform differs from the tax registration number on the matched Oracle Fusion TCA Party record. Matches party to commerce customer on the connector’s configured identity key, then compares the normalised tax-ID strings. Counts the customer, not the number of differing fields. |
| Currency | n/a. This is a count metric. |
| Business Unit scope | Respects the dashboard’s Business Unit filter, derived from each party’s customer-account assignments. B2B parties only; consumer (Person) parties are excluded. |
| Time window | 30D. Evaluated over the trailing 30-day customer-activity window so the card focuses on accounts that are actually transacting. |
| Alert trigger | >0. Any mismatch raises a finding, because a single wrong tax registration number on an active cross-border B2B account is a live compliance risk. |
| Roles | owner, finance, operations |
Calculation
Calculated automatically from your Oracle ERP Cloud data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A US Fortune 500 distributor selling cross-border B2B into the UK and EU, running Oracle ERP Cloud for finance and a B2B commerce platform for ordering. The 30-day window covers 14 Mar 26 to 12 Apr 26.| B2B customer | Commerce tax ID | Fusion Party tax ID | Mismatch type |
|---|---|---|---|
| Daventry Wholesale Ltd | GB 821 4477 90 | GB 821 4477 09 | Transposed digits |
| Venlo Trading BV | NL 8123 456 78 B01 | (blank) | Missing on Fusion |
| Lyon Distribution SARL | FR 40 123456789 | FR 32 123456789 | Wrong check key |
| Hamburg GmbH | DE 811234567 | DE 811234567 | (matches, not flagged) |
| Mismatches (this card) | 3 |
- Three mismatches, alert fired. The threshold is greater than zero, so the Nerve Centre raises a finding on any non-zero reading. Three active cross-border B2B accounts with the wrong tax registration number is three potential reverse-charge failures.
- The transposed-digit case (Daventry) is the most dangerous because it looks valid. GB 821 4477 90 versus GB 821 4477 09 both pass a length check; only a proper VAT validation or a character-exact comparison catches it. An invoice issued under the wrong-but-plausible number can be rejected on the customer’s VAT return and trigger a correction.
- The blank-on-Fusion case (Venlo) breaks the reverse charge outright. If Oracle has no tax registration number for an EU B2B customer, the E-Business Tax engine cannot apply the intra-community reverse charge and may default to charging local VAT, which is both wrong and a cash-flow hit to the customer.
- The wrong-check-key case (Lyon) is a data-entry or migration error. A French VAT number’s two-digit key is computed from the SIREN. A mismatched key means one side was keyed or migrated incorrectly. The fix is to validate against the official registry and correct the master, then confirm which open invoices need reissuing.
- The matching Hamburg account is correctly not flagged. This is the control case: identical normalised strings on both sides produce no finding. The card only surfaces genuine divergence, so a zero reading means your B2B tax master is in sync.
Sibling cards merchants should reference together
Tax-ID mismatch is one of several customer-master integrity signals between commerce and Oracle. Pair it with these to see the full data-hygiene picture.| Card | Why pair it with TaxRegistrationNumber Mismatch |
|---|---|
| Ecom Customers Absent from Fusion Party | The sister integrity card. One finds customers missing from Oracle entirely; this one finds customers present but with conflicting tax data. |
| New Party Records (30d) | Newly onboarded B2B parties are the most common source of fresh mismatches. |
| Active Customers | The transacting base; a mismatch on an active account is more urgent than on a dormant one. |
| Top Customers by Revenue | Prioritise: a mismatch on a top-10 revenue account is a far larger exposure than one on a tail account. |
| Customer Churn Signals | A customer disputing an incorrectly-taxed invoice is a churn risk; the two signals often move together. |
Reconciling against Oracle ERP Cloud
Where to look in Oracle ERP Cloud:Navigator → Customer Data Management → Manage Parties (open the party, Tax Profile / Tax Registrations region) Navigator → Receivables → Billing → Manage Customers (Tax Profile on the customer account) Reports and Analytics → OTBI → Trading Community Real Time / Tax Subject Area (party tax registration number by party)The Tax Registrations region on the party in Customer Data Management holds the authoritative Fusion value the card compares against. Open the flagged party there, read the registered tax number, and compare it character for character with the value on the commerce platform’s customer record. OTBI on the Tax subject area lets you pull the full list of party tax registration numbers to bulk-compare. Common mistakes when comparing against Oracle’s own reports:
- Comparing formatted strings instead of normalised values. “GB821447790”, “GB 821 4477 90”, and “821447790” can be the same registration with different formatting. The card normalises (strips spaces, case, and separators) before comparing; a manual eyeball check that ignores formatting can flag false mismatches or miss real ones.
- Reading the account tax profile instead of the party tax registration. Fusion holds tax data at both party and account level. The card compares the party-level registration. Reading the wrong level can show a difference that is not the one the card flagged.
- Forgetting multiple registrations per party. A B2B party trading in several EU states can hold several VAT registrations. The card matches on the registration for the transacting jurisdiction; comparing against the wrong country’s registration looks like a mismatch when it is not.
| Reason | Direction | Why |
|---|---|---|
| Normalisation rules | Either | The card strips formatting before comparing. A raw string comparison in OTBI flags formatting-only differences the card ignores. |
| Party vs account tax profile | Either | The card compares party-level registration; an account-level comparison can differ. |
| Multiple jurisdiction registrations | Card lower | A party with several VAT numbers matches on the transacting jurisdiction; a naive single-field compare can over-flag. |
| Identity-match key | Either | The card matches commerce customer to Fusion party on the connector’s configured key. A weak key can under- or over-match. |
| Sync timing | Small | A correction made on either side appears at the next sync; a just-fixed record can show as mismatched for one cycle. |