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.
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.
Five things to notice:
- 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-platform 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
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.
Cross-connector reconciliation:
The cross-platform value is that the ecommerce platform takes the order regardless of whether Sage has ever heard of the customer. The storefront does not need a customer master to sell; Sage needs one to account. The gap between the two is invisible to anyone looking at either system alone, and it only gets expensive at month-end when finance discovers a pile of orders that cannot be classified. This card moves the discovery to the moment the order lands, while the fix is a one-record sync rather than a close-week fire drill. This is one of the cleanest demonstrations of the Sage-vs-ecommerce join, and where a Vortex IQ Implementation Partner usually shows finance the first concrete time saving.
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.