Distinguish business and consumer accounts using an explicit decision rule combining company name, tax-relevant characteristics, customer choice and existing ERP identity, rather than one isolated field. Conflicting signals must send the order for review, because classification affects relationship data, billing address and AFAS processing.
Why a company name is not conclusive evidence
A consumer might enter “home” or an association in the company field; a sole trader may order without a company name; an existing business customer may use a private delivery address. VAT numbers are not mandatory or immediately validated at every checkout either. A simple rule such as “company name entered = business” appears efficient, but shifts errors into administration and invoicing.
Start with the purpose of classification. Are you deciding which existing AFAS relationship the order belongs to, which invoice fields are mandatory or which commercial conditions apply? These are different decisions. For each, identify the authoritative source and the signals that merely support it. Broader data ownership belongs in the design of a reliable online store–ERP integration.
A practical decision table
| Existing ERP identity | Checkout signals | Outcome |
|---|---|---|
| Confirmed business | Consistent customer number and company | Use the existing business relationship |
| Confirmed consumer | No business characteristics | Use the consumer relationship |
| No confirmed identity | Company plus sufficient required details | Business candidate under the policy |
| No confirmed identity | Company name only | Do not decide automatically without an additional rule |
| Identity and checkout contradict each other | Mixed signals | Review task before writing externally |
The exact rules depend on your process and tax setup; have the responsible finance team approve them. This article offers process and software guidance, not tax or legal advice.
Fictional example: sole trader order without a company field
Fictional example: Alex orders for design studio Maanveer but uses an express checkout that leaves the company field empty. The email address and customer number do refer to a previously confirmed business relationship in AFAS. The integration uses that existing identity and does not treat the empty field as evidence that Alex is now a consumer. The order retains the chosen delivery address, while billing and relationship data come from the valid link.
On a second order, the system finds the same email address on two relationships without a customer number. Instead of taking the first match, it creates a task with both candidates and relevant, minimised context. The employee chooses and gives a reason. This fictional example demonstrates the difference between a strong existing link and a coincidental email match.
Governance for customer account classification
- For each outcome, document which fields are mandatory and which are merely indicative.
- Create a test set covering a consumer, sole trader, branch, association and guest order.
- Measure how many orders require manual attention because signals conflict.
- Do not change established relationship data based on one order with different delivery details.
- Retain the chosen destination identity for subsequent orders with demonstrably the same customer context.
- Have the finance team periodically review a sample of automatic decisions.
In Connect classification can be applied before the AFAS step. Where ambiguity exists, Desk shows the order and recovery action to the right owner. An uncertain detail then does not silently become permanent contamination of relationship data.
Design the outcome to be revisable too. An organisation's legal form, checkout or customer relationship can change; a stored label must not become an eternal truth without provenance. Retain the signals and rule version that produced the classification. When an employee corrects it, record whether that applies only to the order, to future orders or to the linked relationship. Report unknown and manually reviewed cases separately rather than silently classifying them as consumers. That unknown segment is particularly useful for finding missing checkout fields or inadequate matching rules. Test a rule change against historical, anonymised examples first and discuss changed outcomes with finance before activating it.
Finally, make the manual task small enough to perform well. Show the conflicting signals, possible relationships and effect of each choice rather than the entire customer record. Require a reason for departing from the proposed outcome. Those reasons later provide focused input for better rules without a model or developer having to guess why staff decided differently.
Want to make your online store's classification rules explicit and testable? Discuss your customer account workflow with Yindle.