Ecommerce customers with no matching record in the Sage customer master. Sync gap that breaks invoice classification and VAT line coding.
At a glance
The count of ecommerce customers placing orders who have no matching record in the Sage customer master. Every one of these is an order whose invoice cannot be classified, coded to the right nominal account, or assigned the correct VAT treatment without manual intervention, because the customer the order belongs to does not exist in the book of record. This is the plumbing card behind clean month-end: when it reads high, your finance team is hand-keying customer records during close, and the risk of mis-coded VAT and mis-stated AR rises with it.
| What it counts | The distinct count of ecommerce customers (by the configured match key) who have placed at least one order and have no corresponding record in the Sage customer master. The match key is typically email, customer reference, or VAT registration number for B2B. Customers matched successfully are excluded; the card surfaces only the gap. |
| Match key | Email is the default for DTC. For B2B, the VAT registration number or an account reference is the more reliable key because email varies by ordering contact. The field map sets the precedence (try VAT number, then account reference, then email). |
| Customer types | Both DTC and B2B customers are counted, but the consequences differ sharply. A missing B2B customer breaks VAT-line classification on the next invoice batch; a missing DTC customer is usually a lower-stakes posting cleanup. The card flags the B2B subset prominently. |
| Currency | Not applicable. This is a count metric. The financial exposure is sized through the orders attached to the missing customers, surfaced in the drill. |
| Entity scope | Card respects the dashboard entity filter. In Multi-Entity Console a customer may exist in one entity’s master and not another; the card evaluates against the entity the order should post to. |
| Time window | 7D |
| Alert trigger | >10, sentiment customer_master_gap. Configurable per workspace. Higher-volume DTC operations relax the count; B2B operations often set it to >0 for the B2B subset because each missing B2B customer is a VAT risk. |
| Roles | owner, finance, operations |
Calculation
Calculated automatically by joining your connected ecommerce platform’s customer and order records against 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 merchant on Sage Intacct (single entity, GBP, UK VAT-registered, MTD-compliant) selling through Shopify Plus DTC and a BigCommerce B2B portal. Snapshot 14 Apr 26, evaluating the last 7 days of orders. The card reads 34 absent customers, above the 10 alert line. The finance lead opens the drill and splits the gap by customer type.| Cohort | Count | Orders attached (7d) | Consequence if not fixed before close |
|---|---|---|---|
| New DTC customers (first order, email-only) | 21 | 21 | Posts to a generic web-sales customer; AR analysis loses the detail |
| Returning DTC, email changed | 6 | 9 | Duplicate customer risk; AR splits across two records |
| New B2B accounts (no master record yet) | 5 | 14 | VAT-line classification fails; manual coding at close |
| B2B, VAT number not yet keyed | 2 | 7 | Reverse-charge treatment cannot be applied automatically |
| Ecom Customers Absent from Sage (this card) | 34 | 51 |
- The headline 34 is not 34 equal problems; the 7 B2B customers are worth more attention than the other 27 combined. A missing DTC customer usually posts to a generic web-sales customer record and the only loss is analytical granularity in AR. A missing B2B customer breaks VAT-line classification on the next invoice batch, which is a compliance exposure, not just a tidiness issue. The card surfaces the count, but the drill is where the priority lives: fix the B2B subset today, batch the DTC subset into the normal sync cleanup.
- The 5 new B2B accounts with no master record are the urgent cohort because their invoices cannot be coded correctly without a customer. Sage Intacct needs a customer record to apply the right nominal account, the right AR sub-ledger, the right payment terms, and the right VAT treatment. Without it, the 14 orders attached to those accounts either post to a holding account and get hand-corrected at close, or they stall the invoice batch entirely. Creating the 5 master records (or letting Sage Network sync create them) clears 14 orders’ worth of manual work.
- The 2 B2B customers missing a VAT number are a reverse-charge risk specifically. UK B2B transactions and cross-border EU transactions rely on the customer’s VAT registration number to apply reverse-charge accounting correctly. If the VAT number is absent from the Sage customer master, the system cannot decide whether to charge VAT, zero-rate, or apply the reverse charge, and the safe default (charge standard VAT) may be wrong, creating a VAT return error that surfaces in Revenue Lines Missing VAT Code (MTD). This is the kind of error HMRC penalises under Making Tax Digital.
- The 6 returning DTC customers with changed emails are a duplicate-record trap, not a true absence. These customers exist in Sage under their old email; the new order arrives under a new email and fails to match, so the card counts them as absent. If finance creates a new master record rather than merging, the customer’s AR splits across two records and their true balance and lifetime value fragment. The right move is to match on a secondary key (name plus postcode, or phone) before creating anything. The card flags the suspected-duplicate subset where a fuzzy match exists.
- This card is the upstream cause of several downstream finance cards, which is why fixing it pays compound dividends. A customer absent from the master shows up later as a VAT-coding gap, an unclassified revenue line, a fragmented AR balance, and a customer that cannot be credit-checked. Working this card to near zero each week removes the root cause of all of them. The cross-channel point is that the ecommerce platform happily takes the order without caring whether Sage knows who the customer is; only the join between the two systems reveals the gap, and only before close does fixing it stay cheap.
Sibling cards merchants should reference together
| Card | Why pair it with Ecom Customers Absent from Sage |
|---|---|
| Ecom Customers Absent from Sage Customer Master | The cross-channel B2B-with-active-orders cut of this gap, weighted to Sage Network sync and VAT consequences. |
| B2B Customers with VAT Number Mismatch (ecom vs Sage) | The next failure mode: the customer exists but the VAT number disagrees across systems. |
| Revenue Lines Missing VAT Code (MTD) | The downstream symptom. A missing customer is a common cause of an unclassified VAT line. |
| Sage Active Customers | The denominator. This card is the gap between who is buying and who Sage knows about. |
| Commerce Orders without Sage Intacct Order | The order-level sibling of this customer-level gap. Both trace to the same sync. |
| New Customers (30d) | New customers are the most common source of absent records before the first sync runs. |
| Customer Credit Utilisation | A customer absent from the master cannot be credit-checked, which is a B2B risk. |
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 canonical customer master this card joins against Reports → Accounts Receivable → Customer List exported and compared by email and VAT number against the ecommerce customer export Sage Network / sync logs (where the connector or Sage Network is responsible for creating customer records from inbound orders, the log shows which records were created, skipped, or failed to match) Interactive Custom Report (ICR) on the Customer data source listingThe reconciliation discipline is matching on the same key the card uses. If finance compares the two customer lists by name, near-misses (Ltd vs Limited, trailing whitespace, trading name vs registered name) read as absent when the card matched them on email or VAT number and counted them as present. Agree the match key first. Common reconciliation pitfalls:CustomerID,CustomerName, email contact, and the VAT registration custom field, to align against the storefront customer list Order Entry → Sales Orders filtered to orders posted against a generic or holding customer, which is where absent-customer orders accumulate when the sync cannot match
- Match-key mismatch. The card may match on VAT number while a manual comparison matches on name. Names are unreliable; VAT number and email are stable. Differences almost always trace to the key.
- Generic holding customer. Orders for absent customers often post to a single generic web-sales customer in Sage. A manual comparison that treats that generic record as a real customer will undercount the gap. The card looks through the generic record to the underlying order.
- Sync timing. A customer created by the overnight sync but ordering this afternoon reads as absent until the next sync runs. The card timestamps the join; a manual comparison pulled mid-cycle catches the same in-flight gap.
| Reason | Direction | Why |
|---|---|---|
| Match-key choice | Either | Card matches on VAT number or email; a manual name-based comparison reads near-misses as absent. |
| Generic holding customer | Card may read higher | Card looks through the generic web-sales record to the real underlying customer; a manual comparison counts the generic record as present and undercounts the gap. |
| Sync timing | Either | A customer created by a sync that ran between the two pulls appears present in one and absent in the other. Card uses an aligned timestamp. |
| Duplicate-email merge | Card may read lower | A returning customer with a changed email is flagged as a suspected duplicate, not a clean absence, where a fuzzy secondary match exists. |
| B2B vs DTC scope | Either | If the field map scopes the card to B2B only, the count excludes DTC absences a full comparison would include. |
| Multi-entity master | Either | A customer present in one entity’s master and absent in another is counted against the entity the order should post to. |
| Inactive customer records | Card may read higher | A customer marked inactive in Sage but still ordering reads as effectively absent for posting purposes; some manual comparisons count inactive records as present. |
| Card | Expected relationship | What the comparison reveals |
|---|---|---|
| shopify.customers | Source side | Shopify’s customer count is the population this card joins against the Sage master. The gap is the absent cohort for the DTC channel. |
| bigcommerce.customers | Source side | Same for the BigCommerce B2B channel, where absences carry the higher VAT-classification stakes. |
| adobe_commerce.customers | Source side | Adobe Commerce B2B company accounts must map to Sage customers; unmapped companies are the absent cohort. |
| Commerce Orders without Sage Intacct Order | Same root cause | Orders missing in Sage and customers missing in Sage usually trace to the same sync gap; reconcile the two together. |
| Revenue Lines Missing VAT Code (MTD) | Downstream | A missing customer is a leading cause of an unclassified VAT line. Fixing this card upstream reduces that card downstream. |
| Ecom Customers Absent from Sage Customer Master | B2B-active cut | The cross-channel view focuses on B2B-flagged customers with active orders and the Sage Network sync consequences. |
Known limitations / merchant FAQs
What is the right match key? For DTC, email is usually adequate. For B2B, the VAT registration number or a stable account reference is far more reliable than email, because the ordering contact’s email changes while the legal entity does not. The recommended precedence is VAT number, then account reference, then email. Set it in the field map; most false absences trace to a weak match key. Why does a returning customer sometimes show as absent? If the customer changed their email, the order arrives under the new email and fails to match the old master record. The card flags these as suspected duplicates where a fuzzy secondary match (name plus postcode, or phone) exists, so finance merges rather than creating a duplicate. Creating a new record fragments the customer’s AR and lifetime value across two records. Does an order for an absent customer still post? Usually to a generic web-sales or holding customer, which keeps the books moving but loses the per-customer detail and breaks B2B VAT classification. The card looks through the generic record to surface the real underlying gap, so the count reflects customers who genuinely need a master record, not the holding account they were parked in. Why is the B2B subset weighted so heavily? A missing B2B customer breaks VAT-line classification on the next invoice batch, which is a compliance exposure under Making Tax Digital, not just lost analytical detail. Many B2B operations set the alert to fire at the first absent B2B customer (>0 on the B2B subset) even while tolerating a larger DTC count.
How does this relate to the VAT number mismatch card?
This card is about customers who do not exist in Sage at all. The mismatch card is about customers who exist but whose VAT number disagrees across systems. They are sequential failure modes: first the customer must exist (this card), then their VAT number must agree (the mismatch card). Work this one first.
Can Sage Network create the missing records automatically?
Where Sage Network or the connector is configured to create customer records from inbound orders, many absences clear automatically on the next sync. This card is most useful as a monitor on that automation: a rising count means the auto-creation is failing or lagging, which is a sync-health signal, not just a data-entry backlog.
How does multi-entity affect the count?
A 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 a customer present in the UK entity but absent from the US entity is counted against the US entity when a US order arrives. Read the per-entity cut to see which entity’s master needs the record.
What about inactive customer records?
A customer marked inactive in Sage but still placing orders is effectively absent for posting purposes, because the order cannot post against an inactive customer. The card counts these. The fix is usually to reactivate rather than recreate, which preserves the historical AR.
How fresh is the count?
The card joins the most recent ecommerce customer and order data against the current Sage customer master. A customer created by an overnight sync appears as present on the next refresh. The card timestamps the join so an in-flight customer (ordered after the last sync) is correctly shown as not-yet-synced rather than permanently absent.
Implementation Partner role on this metric?
The Partner usually owns the customer-creation automation (Sage Network or connector mapping), the match-key precedence, and the holding-customer policy. If this card disagrees with a manual customer-list comparison, the cause is almost always a match-key difference (name vs VAT number) or the treatment of the generic holding customer. Align the match key in the field map and bring the Partner into the customer-sync design early.