Link a delivery address to an AFAS debtor account only when customer identity, address details and origin all match. Finding an account through an email address or postcode alone is insufficient evidence. Validate that the order actually belongs to that account, normalise the address and treat several plausible matches as an exception requiring an employee’s assessment.
An address is more than a text field
Online stores do not always supply street names and house numbers in the same fields. Dutch and Belgian addresses, suffixes and company names introduce variation. A consumer may also use the same email address privately and for business, or family members may share one address. An integration that confuses “looks similar” with “is the same” can place a valid address on the wrong debtor account.
Split the question into two parts: can the address be read reliably by the system, and is the account identity sufficiently strong? Keep the original order fields alongside the normalised form so an employee can see what the customer entered if there is doubt. Treat an existing destination identity from an earlier reliable synchronisation as a stronger signal than a new fuzzy match.
Identity check before updating
- Workspace and store. Search only within the correct organisational context.
- Existing link. Check whether the local order already has a confirmed AFAS debtor-account identity.
- Account signals. Compare customer number, email and relevant company attributes using predefined rules.
- Address parsing. Validate country, postcode, town, street, house number and suffix separately.
- Ambiguity. Stop when there are no convincing candidates or several; never choose the first search result.
- Effect. Determine whether you may change an order delivery address, an account address or both.
For a WooCommerce–AFAS order flow that last point deserves particular attention. A one-off gift address does not need to replace the account’s regular address automatically.
Fictional example: a shared mailbox, two branches
Fictional example: business customer Stadsgroen orders from two branches using `[email protected]`. Order 5810 gives the workshop in Breda as its delivery address. AFAS contains two debtor accounts with that mailbox: the holding company and the regional branch. Searching by email therefore does not identify a unique account.
The integration finds no confirmed link on the order and opens a persistent task requiring attention. The employee compares the customer number from checkout, company name and previous orders, chooses the regional branch and records the confirmed identity. Only the sales order’s delivery address is updated; the holding company’s main address remains untouched. This fictional example shows why a few seconds of automatic “cleverness” can cost much more than a focused task to resolve ambiguity.
A traffic-light model for accepting addresses
| Colour | Situation | Policy |
|---|---|---|
| Green | Confirmed destination identity and fully valid order address | Process with checks |
| Amber | Unique candidate, but a new or different address | Additional rules or human review |
| Red | Several candidates, an unparseable address or a context mismatch | Do not write; create a task for attention |
Connect can bring source fields, identity and the provider step together in a verifiable way. Desk gives the agent relevant order context and one next action for amber and red cases. After a manual choice, record which evidence was used so the next order does not have to go through the same ambiguity again.
Test address logic using real formats but anonymised values. Include edge cases such as a house number with a letter, a hyphenated suffix, a Belgian box number, a PO box, a missing postcode, a long company name and an order with different billing and delivery addresses. Check every field after transformation, not just the combined display. An address can look correct on one line while the house number and suffix end up incorrectly in the ERP. Also define country-specific parsing rules and preserve source fields for review when the country is unfamiliar. Never treat parsing as proof of identity: even a perfectly normalised address does not prove which debtor account owns it. Separate test results for technical readability and account matching.
Finally, avoid silently removing an old delivery address when the destination system needs history. Decide beforehand whether the integration updates an existing address, adds an order-specific address or starts a new validity period. Then use one fictional customer with two simultaneous orders to check that both shipments retain their own destination. This prevents a later order from unintentionally changing an earlier fulfilment instruction and keeps the original customer input available for investigation.
Want to automate address updates without affecting the wrong debtor accounts? Have Yindle develop your identity and address rules.