{"id":125,"date":"2026-10-04T09:00:00","date_gmt":"2026-10-04T07:00:00","guid":{"rendered":"https:\/\/yindle.com\/?p=125"},"modified":"2026-10-04T09:00:00","modified_gmt":"2026-10-04T07:00:00","slug":"zakelijke-particuliere-debiteur-webshopdata","status":"publish","type":"post","link":"https:\/\/yindle.com\/en\/identifying-business-or-consumer-accounts-from-online-store-data\/","title":{"rendered":"Identifying business or consumer accounts from online store data"},"content":{"rendered":"

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.<\/p>\n

Why a company name is not conclusive evidence<\/h2>\n

A consumer might enter \u201chome\u201d 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 \u201ccompany name entered = business\u201d appears efficient, but shifts errors into administration and invoicing.<\/p>\n

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\u2013ERP integration<\/a>.<\/p>\n

A practical decision table<\/h2>\n
\n\n\n\n\n\n\n\n\n\n
Existing ERP identity<\/th>\nCheckout signals<\/th>\nOutcome<\/th>\n<\/tr>\n<\/thead>\n
Confirmed business<\/td>\nConsistent customer number and company<\/td>\nUse the existing business relationship<\/td>\n<\/tr>\n
Confirmed consumer<\/td>\nNo business characteristics<\/td>\nUse the consumer relationship<\/td>\n<\/tr>\n
No confirmed identity<\/td>\nCompany plus sufficient required details<\/td>\nBusiness candidate under the policy<\/td>\n<\/tr>\n
No confirmed identity<\/td>\nCompany name only<\/td>\nDo not decide automatically without an additional rule<\/td>\n<\/tr>\n
Identity and checkout contradict each other<\/td>\nMixed signals<\/td>\nReview task before writing externally<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

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.<\/p>\n

Fictional example: sole trader order without a company field<\/h2>\n

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.<\/p>\n

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.<\/p>\n

Governance for customer account classification<\/h2>\n