Reference data

Concepts

AIOTIC needs three tables from you. They are not "nice to have": they are what turns a document into a bookable order.

Table	Key	Used for
Customers (/customer)	your debtor number	Identifying who sent the order → customer.customer_id
Products (/product)	article number + language code	Deciding whether an article number is valid — the list of everything your ERP will accept
Customer item mappings (/customer-product)	debtor number + the customer's own article code	Translating a customer's code to your article number

Why AIOTIC synchronises your data instead of querying your ERP live

Integrators regularly ask why AIOTIC keeps its own copy of customers, products and mappings rather than looking them up in the ERP at the moment an order is processed. It is a deliberate design choice, for five reasons.

1. Performance you can rely on. Extraction, identification and article resolution run against data that sits next to the AI processing, on AIOTIC's own infrastructure. That is fast, it stays fast under load, and it can be optimised end to end. A live lookup would make every order as slow, and as available, as the ERP's API on that particular day.
2. Normalisation happens at sync time. Master data in most ERPs is not standardised: inconsistent postal codes, VAT numbers with and without spaces, article numbers in three formats, names with legacy markers. When a record is synchronised, AIOTIC normalises it into a canonical form. Documents are matched against that clean form, not against whatever the ERP happens to contain.
3. Independence from the ERP. AIOTIC does not depend on the vendor, version, API style or availability of your business software. Every tenant's data is organised the same way, which is what lets one product deliver consistent results across very different ERPs. Your side of the integration stays small: push changes, receive orders.
4. Enrichment for context. During synchronisation AIOTIC derives additional context from your records — search indexes, alternative identifiers, relations between customers, branches and article codes — so that the processing has as much evidence as possible for every decision. That enrichment is what turns a bare ERP export into an ontology the AI can be held to.
5. Continuous benchmarking per tenant. Because the synchronised data is validated, enriched and organised, AIOTIC can measure results against it and build tenant-specific improvement data: which customers, article formats and document layouts your organisation actually deals with. Accuracy therefore improves for your tenant over time, based on your data.

The trade-off is that your master data must be kept current, which is why this guide spends several pages on doing that efficiently (event-driven, never full dumps). A live connection would trade that small, one-time integration effort for slower processing, ERP-dependent behaviour and none of the normalisation and enrichment above.

Rendering diagram…

Where each line's article number comes from, and why a missing product record ends in ATTENTION.

Customers

One record per debtor you can book an order for. The more fields you fill, the better the identification: company name, street, postal code, city, VAT number, e-mail, phone, Chamber of Commerce number and website all count as evidence.

PUT /customer/58931
{
  "name": "LUMITECH INSTALLATIES",
  "address": "Ambachtsweg 12",
  "postal_code": "7327 AA",
  "city": "Apeldoorn",
  "vat_number": "NL001234567B01",
  "email": "info@lumitech.example",
  "phone_number": "+31 55 123 4567",
  "contact_person": "J. de Boer",
  "coc_number": "12345678",
  "home_page": "https://www.lumitech.example"
}

Things AIOTIC does with this record that you should know:

• Identification is evidence-based and multi-stage. Hard identifiers printed on the order (a customer number, a VAT number, a known e-mail address) weigh more than softer evidence such as address similarity or the customer's own article codes. A confident match sets customer_id; an ambiguous one leaves it null and flags the order for a person.
• Multi-branch customers. If you keep one debtor per branch (same name, same VAT, different town), AIOTIC can still tell them apart when the document names the branch. Keep city accurate per branch.
• Archiving by name. A record whose name carries a legacy marker (formerly, voorheen, (old), do not use, closed, failliet, …) is archived automatically: it is never chosen, but explicit references to it still resolve for audit. See Archiving.
• "See customer N" markers. A name like *** ZIE 12306 *** makes the record redirect to debtor 12306. See Archiving.
• On a confident match, the customer block in the payload is canonicalised from your record — which is why stale addresses in AIOTIC show up in orders.

Products

One record per article number per language. The description is what the product is called in that language; remark is free.

PUT /product/PROD-001/nl
{ "description": "LED Driver 48V 100W", "remark": "Incl. montagebeugel" }

• The product table is the definition of a valid article number. After extraction, every line's article_number must exist here; otherwise the order goes to ATTENTION. A missing product record is the single most common cause of ATTENTION.
• AIOTIC tolerates format differences deterministically: leading zeros (620206_01 vs 0620206_01), suffix padding (_1 vs _01), and separator variants (./- vs _) are matched to the canonical SKU when the match is unique. It never invents a SKU.
• Language codes are yours to choose (nl, de, en…). If you only maintain one language, use one code consistently and pass the same code in mappings.

Customer item mappings

Many customers print their article numbers on purchase orders. A mapping says: when customer 58931 writes LT-ART-001, they mean PROD-001.

PUT /customer-product/58931/LT-ART-001
{ "item_number": "PROD-001", "language_code": "nl" }

Both the customer and the product must already exist (404 otherwise). Mappings also act as identification evidence: three or more of a customer's codes on one document strongly suggest who sent it.

How article numbers are resolved

For each line AIOTIC works through a fixed series of stages and stops at the first hit:

1. the article code printed on the document, if it exists in products;
2. a format-only variant of it (leading zero, suffix padding, separator) that maps to exactly one product;
3. the customer's own code through customer item mappings (needs an identified customer).

Anything still unresolved leaves article_number null and the order in ATTENTION. When operators fix such a line in the AIOTIC app, consider adding the mapping so the next order resolves automatically — the customer_item_number on the line tells you what to map.

Sizing

Data	Typical size	Sync approach
Customers	1 000 – 50 000	event-driven, nightly reconcile
Products	5 000 – 500 000	event-driven only; reconcile weekly or on demand
Mappings	0 – 100 000	event-driven; grow from operator corrections

See Keeping data in sync.