> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Ecom Customers Absent from Sage Customer Master, Sage > Sage Network sync gap. B2B-flagged ecom customers missing in Sage means VAT-line classification fails on the next invoice batch. How to read it, why it matters, and how to act on it. **Card class:** [Cross-Channel](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > Sage Network sync gap. B2B-flagged ecom customers missing in Sage means VAT-line classification fails on the next invoice batch. ## At a glance > The count of B2B-flagged ecommerce customers with active orders who have no record in the Sage customer master, framed specifically as a Sage Network sync-health and VAT-classification problem. This is the cross-channel cut: not every absent customer, but the B2B customers placing real orders right now whose missing master record will break VAT-line coding on the next invoice batch. Where the platform-level [Ecom Customers Absent from Sage](/nerve-centre/kpi-cards/sage/ecom-customers-absent-from-sage) card counts the whole gap including low-stakes DTC absences, this card narrows to the high-consequence intersection: B2B, active orders, imminent invoicing, VAT at stake. | | | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | The distinct count of B2B-flagged ecommerce customers with at least one active order who have no matching record in the Sage customer master, where the match would normally be created or maintained by the Sage Network sync or the connector. The card is the B2B-with-active-orders intersection, not the full absent population. | | **Sage Network framing** | The card reads as a sync-health monitor. A rising count means the Sage Network or connector customer-creation flow is failing or lagging for inbound B2B orders, which is the upstream cause, not just a data-entry backlog. | | **Match key** | VAT registration number first, then account reference, then email, because B2B contact emails vary while the legal entity does not. The field map sets precedence. | | **VAT consequence** | Each absent B2B customer means the next invoice cannot be coded with the correct VAT treatment (standard, zero-rated, or reverse-charge), because the customer record that carries the VAT number and tax schedule does not exist. This is the headline consequence the card is built around. | | **Currency** | Not applicable. Count metric. The exposure is sized through the active orders attached to the absent customers, surfaced in the drill. | | **Entity scope** | Card respects the dashboard entity filter. A customer present in one entity's master and absent from another is counted against the entity the order should post to. | | **Time window** | `7D` | | **Alert trigger** | `>10 with active orders absent`, sentiment `customer_master_gap`. Configurable per workspace. B2B operations frequently tighten because each absent customer with an active order is an imminent VAT-coding failure. | | **Roles** | owner, finance, marketing, operations | ## Calculation Calculated automatically by joining B2B-flagged ecommerce customers with active orders against the Sage customer master, scoped to the records the Sage Network sync should be maintaining. 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) running a BigCommerce B2B portal and an Adobe Commerce wholesale store, with customer records maintained through a Sage Network sync. Snapshot 14 Apr 26, last 7 days. The card reads 14 absent B2B customers with active orders, above the 10 alert line. The finance lead opens the drill, which groups by the suspected sync cause. | Sync cause | Count | Active orders attached | VAT consequence on next batch | | --------------------------------------------- | ------ | ---------------------- | ---------------------------------------------------- | | New B2B accounts, never synced | 6 | 19 | No customer record; VAT treatment cannot be assigned | | Sync failed (validation error on create) | 4 | 11 | Record creation rejected; orders stranded | | Sync lagging (created on storefront today) | 3 | 7 | Will clear on next sync; not a true failure | | Account merged on storefront, old ref absent | 1 | 2 | Orphaned order references a retired account | | **Absent B2B with active orders (this card)** | **14** | **39** | | Five things to notice: 1. **The card reframes an absence count as a sync-health alarm, which is what makes it different from the platform-level absent-customer card.** The platform card answers "who is missing"; this card answers "is the Sage Network sync keeping up with inbound B2B orders, and what will break if it is not". The 6 never-synced accounts and the 4 failed-create accounts are real sync problems; the 3 lagging accounts are a timing artefact that clears on the next run. Splitting failure from lag is the operational value: chase the 10 real failures, ignore the 3 that will self-resolve. 2. **The 4 sync-failed-on-create accounts are the most dangerous because the orders are stranded and someone thinks the sync is working.** A new B2B account that never synced is at least visibly missing; an account where the sync attempted creation and was rejected (a validation error, a duplicate-key collision, a missing mandatory field) leaves 11 orders stranded while the dashboard shows a sync that "ran". The card surfaces the rejection so the team fixes the underlying validation problem rather than waiting for a sync that will keep failing the same way. This is the classic silent-failure that only the join exposes. 3. **The VAT consequence is the same for every real absence and it is the reason finance owns this card.** Without a customer record, Sage cannot assign the correct tax schedule, so the next invoice batch cannot apply standard-rate, zero-rated, or reverse-charge treatment correctly. For a UK B2B merchant trading cross-border, this is a direct line to a VAT return error, which is why [Revenue Lines Missing VAT Code (MTD)](/nerve-centre/kpi-cards/sage/revenue-lines-missing-vat-code-mtd) tends to rise in lockstep with this card. Clearing the absent customers upstream prevents the VAT-coding gap downstream. 4. **Marketing is on the roles list for a reason that is easy to miss.** B2B accounts are often created through a marketing-led onboarding flow (a trade-application form, a wholesale signup, a rep-assisted account setup). When those flows do not carry the fields the Sage Network sync needs (legal name, VAT number, billing entity), the create fails and the customer lands on this card. Marketing owning the quality of the onboarding capture is the upstream fix; finance chasing the absent records at close is the downstream symptom. The card makes that handoff visible. 5. **This is a pure cross-channel finding: the storefront accepted 39 B2B orders for customers Sage has never successfully recorded.** The storefront does not need a Sage record to take a B2B order; Sage needs one to invoice it correctly. The Sage Network sync is the bridge, and when it lags or fails, the gap is invisible to anyone watching either system alone. Only the join shows that 14 active B2B customers with 39 live orders are about to hit an invoice batch that cannot code their VAT. On this account the finance lead traced the 4 failed-create accounts to a single missing mandatory field in the trade-application form, fixed the form, and the recurring failure stopped. That is the kind of root-cause fix the cross-channel view enables and a single-system dashboard never surfaces. ## Sibling cards merchants should reference together | Card | Why pair it with Ecom Customers Absent from Sage Customer Master | | ----------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | [Ecom Customers Absent from Sage](/nerve-centre/kpi-cards/sage/ecom-customers-absent-from-sage) | The platform-level superset. This card is the B2B-with-active-orders, sync-health cut of it. | | [B2B Customers with VAT Number Mismatch (ecom vs Sage)](/nerve-centre/kpi-cards/sage/b2b-customers-with-vat-number-mismatch-ecom-vs-sage) | The next failure mode: the customer exists but the VAT number disagrees. | | [Revenue Lines Missing VAT Code (MTD)](/nerve-centre/kpi-cards/sage/revenue-lines-missing-vat-code-mtd) | The downstream symptom. Absent B2B customers are a leading cause of unclassified VAT lines. | | [Commerce Orders without Sage Intacct Order](/nerve-centre/kpi-cards/sage/commerce-orders-without-sage-intacct-order) | The order-level sync gap. The same Sage Network sync drives both. | | [Current VAT Return Status (MTD)](/nerve-centre/kpi-cards/sage/current-vat-return-status-mtd) | The end of the chain. Absent customers contaminate the live return. | | [Sage Active Customers](/nerve-centre/kpi-cards/sage/sage-active-customers) | The denominator. The gap between active ecom B2B buyers and the Sage master. | | [New Customers (30d)](/nerve-centre/kpi-cards/sage/new-customers-30d) | New B2B accounts are the most common source of sync-create failures. | | [Sage Top B2B Accounts](/nerve-centre/kpi-cards/sage/sage-top-b2b-accounts) | Prioritise sync fixes on your highest-value accounts first. | ## 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** list, the customer master the Sage Network sync maintains and this card joins against > **Sage Network / sync logs** (the authoritative record of which customer creates succeeded, were skipped, or failed, and the rejection reason on each failure) > **Reports → Accounts Receivable → Customer List** exported and compared by VAT number and account reference against the storefront's B2B customer export > **Order Entry → Sales Orders** filtered to a generic or holding customer, where stranded B2B orders accumulate when the create fails > **Interactive Custom Report (ICR)** on the Customer data source listing `CustomerID`, account reference, and the VAT field, joined against the storefront B2B customer list to confirm the absent set The reconciliation discipline here is reading the Sage Network sync log, not just the customer list. A customer absent from the list might be a create that was attempted and rejected (a sync failure with a root cause) rather than one that was never attempted (a backlog). The log tells you which, and the fix differs: a backlog needs a sync run, a failure needs the rejection reason fixed first. Common reconciliation pitfalls: * **Failure vs lag vs never-attempted.** The customer list alone cannot distinguish these. The sync log can. Treating a recurring create-failure as a backlog means re-running a sync that will fail the same way. * **Match-key choice.** The card matches B2B customers on VAT number or account reference; a manual name-based comparison reads near-misses (Ltd vs Limited) as absent. * **B2B flag scope.** This card counts only B2B-flagged customers. A manual comparison that includes DTC will read a larger number; the difference is the DTC absences this card deliberately excludes. **Why our number may legitimately differ from a manual customer-list comparison:** | Reason | Direction | Why | | ---------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | **B2B scope only** | Card may read lower | Card counts only B2B-flagged customers with active orders; a full comparison includes DTC and dormant absences. | | **Active-order requirement** | Card may read lower | Card requires at least one active order; an absent customer with no current order is out of scope here. | | **Sync-failure vs backlog** | Either | Card can read the sync log to separate failures from lag; a list-only comparison conflates them. | | **Match-key choice** | Either | Card matches on VAT number or account reference; a name-based comparison reads near-misses as absent. | | **Generic holding customer** | Card may read higher | Card looks through the holding customer to the real underlying B2B account; a manual comparison counts the holding record as present. | | **Sync timing** | Either | A customer created by a sync that ran between two pulls is present in one and absent in the other. Card uses an aligned timestamp. | | **Multi-entity master** | Either | A B2B customer present in one entity and absent from another is counted against the entity the order should post to. | **Cross-connector reconciliation:** | Card | Expected relationship | What the comparison reveals | | --------------------------------------------------------------------------------------------------------------------- | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | [bigcommerce.customers](/nerve-centre/bigcommerce/customers) | Source side | BigCommerce B2B company accounts are the population the Sage Network sync should be creating. Unmapped companies are this card's rows. | | [adobe\_commerce.customers](/nerve-centre/adobe_commerce/customers) | Source side | Adobe Commerce B2B company profiles must map to Sage customers; failed creates strand the company's orders. | | [shopify.customers](/nerve-centre/shopify/customers) | Source side | Shopify B2B (companies) feed the same sync; the wholesale-channel B2B absences appear here. | | [Commerce Orders without Sage Intacct Order](/nerve-centre/kpi-cards/sage/commerce-orders-without-sage-intacct-order) | Same sync | Absent customers and absent orders both trace to the Sage Network sync; reconcile them together. | | [Revenue Lines Missing VAT Code (MTD)](/nerve-centre/kpi-cards/sage/revenue-lines-missing-vat-code-mtd) | Downstream | Absent B2B customers are a leading cause of unclassified VAT lines on the next batch. | | [Ecom Customers Absent from Sage](/nerve-centre/kpi-cards/sage/ecom-customers-absent-from-sage) | Superset | The platform-level card counts the whole absent population; this card is the high-consequence B2B-active subset. | The cross-channel high-leverage finding is that the Sage Network sync is a bridge between two systems that each work perfectly well alone, and a bridge failure is invisible from either bank. The storefront keeps taking B2B orders and shows healthy sales. Sage keeps invoicing the customers it knows about and shows a clean ledger. Neither flags the customers whose records never crossed the bridge, and the failure only surfaces at the invoice batch when the VAT coding breaks, by which point finance is hand-fixing during close week. This card watches the bridge directly, separates real failures from harmless lag, and ties each absence to the orders and the VAT exposure waiting behind it. For a UK B2B merchant it is one of the clearest demonstrations of why the Sage-vs-ecommerce join matters, and it is frequently where the Vortex IQ Implementation Partner proves the value of cross-channel monitoring to finance and operations together. ## Known limitations / merchant FAQs **How is this different from Ecom Customers Absent from Sage?** The platform-level card counts the whole absent population, including low-stakes DTC customers and dormant accounts. This card narrows to the high-consequence intersection: B2B-flagged customers with active orders whose missing record will break VAT coding on the next invoice batch, framed as a Sage Network sync-health alarm. Same underlying gap, sharper and more urgent cut. **Why is this framed around Sage Network sync rather than just data entry?** Because for B2B customers the records are normally created and maintained by the Sage Network sync or the connector, not hand-keyed. A rising count therefore means the automation is failing or lagging, which is an upstream sync-health problem with a single root-cause fix, not a manual backlog to grind through. Reading the sync log is the first diagnostic step. **What is the difference between a sync failure and a sync lag?** A lag is a customer created on the storefront recently whose record will appear on the next sync run; it self-resolves. A failure is a create the sync attempted and the system rejected (validation error, duplicate key, missing mandatory field); it will keep failing until the root cause is fixed. The customer list alone cannot tell them apart; the sync log can. Chase failures, ignore lag. **Why is marketing on the roles list?** B2B accounts are often created through marketing-led onboarding flows (trade applications, wholesale signups). If those flows do not capture the fields the sync needs (legal name, VAT number, billing entity), the create fails and the customer lands here. The upstream fix is improving the onboarding capture, which marketing owns. Finance chasing the absences at close is the downstream symptom. **Does the active-order requirement mean some absent customers are hidden?** Yes, by design. An absent B2B customer with no current order is a lower priority because no invoice is imminent. This card focuses on the customers whose absence will cause a problem on the next batch. The platform-level absent-customer card catches the rest. **What is the VAT consequence exactly?** Without a customer record, Sage cannot assign the customer's tax schedule, so the invoice cannot apply standard-rate, zero-rated, or reverse-charge treatment correctly. For UK and cross-border EU B2B this means a wrongly treated invoice that contaminates the VAT return, an MTD exposure HMRC can penalise. The customer record is the carrier of the VAT number and tax schedule that make correct coding possible. **Can Sage Network create the records automatically?** That is exactly what it is meant to do, and this card monitors whether it is succeeding. When the sync works, absences clear on the next run. When it fails, this card rises and the sync log holds the rejection reason. Treat a rising count as a signal to inspect the sync, not as a queue to hand-key. **How does multi-entity affect the count?** A B2B customer can exist in one entity's master and be absent from another. The card evaluates against the entity the order should post to, so an order arriving for the US entity is checked against the US master. Read the per-entity cut to see which entity's sync is failing. **How fresh is the count?** The card joins the most recent B2B order and customer data from the storefront against the current Sage master, timestamping the join so an in-flight customer (created after the last sync) is shown as not-yet-synced rather than permanently absent. A customer created by an overnight sync appears as present on the next refresh. **Implementation Partner role on this metric?** The Partner usually owns the Sage Network sync configuration, the customer-create field mapping, and the mandatory-field validation that causes most create failures. If this card reads high, the cause is almost always a sync-create rejection (a missing mandatory field captured wrong in the onboarding flow) or a match-key gap. Bring the Partner in to read the sync log and fix the create flow at source; it is the same mapping that drives the order-sync and VAT-mismatch cards. *** ### Tracked live in Vortex IQ Nerve Centre *Ecom Customers Absent from Sage Customer Master* 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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.