Documentation
How EnterDocs reads a document, what it compares that reading against, and how to drive both from your own systems.
Integration guide
Connect two readers, point an inbox at the queue, and release one supplier at a time.
OpenAPI reference
Every endpoint with example requests and responses. Runnable against this deployment.
OpenWhy two readers
Every document goes through two extraction engines from different vendors. Where they return the same value, nothing else has to happen. Where they differ, four mechanisms are tried in order of cost before a person is asked:
- 1
Arithmetic
The document has to close on itself. Line items sum to the net; net plus VAT reaches the gross. When only one of two candidate totals satisfies that, the other is ruled out — with certainty rather than with probability. There is no model in this step, and it is the strongest one.
- 2
Check digits
OIB carries ISO 7064 MOD 11,10 and IBAN carries MOD 97. We measured the detection rate on the fixtures in this build: 693 of 693 single-digit OIB corruptions rejected, and 612 of 612 for IBAN. A misread identifier is detectable, not merely doubtful.
- 3
Known values
When the answer is already in a list we hold — this supplier's OIB, their established account, an article code in the catalogue — matching beats reading. The list is the supplier record, which is why synchronising it first is the advice in the guide.
- 4
Template memory
The fortieth invoice from a supplier has the same layout as the previous thirty-nine. Once a field's position is learned per supplier, extraction stops being inference and becomes a lookup.
Only then does a person see it — and when they do, the interface says which of the four was tried and could not help. A field that reaches you without that sentence is a field nobody tried to settle.
What the product is organised around
The order is the argument. Extraction is step one and step one is not a product — every accounting tool on the market reads an invoice.
Read
What does the document say?
Two independent readers extract every field, and where they disagree the arithmetic of the document decides between them. Confidence scores stop being the last word — a total that the line items add up to is not a guess.
Check
Does it agree with everything else?
A correctly read invoice can still be wrong. The bank account changed, the quantity is not the one on the delivery note, the unit price has drifted four times this quarter — none of that is visible in the document, only against the ones before it.
Post
Which account does it belong to?
The slow part of bookkeeping is not typing the total, it is deciding the account, the VAT treatment and the cost centre. Each supplier earns its own autonomy: suggested at first, posted without stopping once the record supports it, demoted the moment corrections return.
Prove
Where did this figure come from?
Every posted figure carries the page it was read from, the box it sat in, which reader produced it, what settled the disagreement and who approved it. A period closes when nothing is unmatched, unread or unexplained — and the checklist says which.
What this deployment is
Every screen, flow and business rule works. The extraction engines are not connected: the readings you see were produced by the same settlement code that would run in production, over documents written as fixtures. Every OIB and IBAN in them is arithmetically valid, generated against the real algorithms and verified — except one, which is invalid on purpose so that the identifier check has something to catch.



