Set the boundary before reading the document
The contract’s outcome is a draft bill in the selected company. It does not approve the invoice, post an accounting transaction, release a payment, or create a new supplier. Those exclusions determine the connection’s permissions and the receipt’s language.
The source document is evidence to interpret, not authority to expand the operation. A note saying “pay immediately” cannot enable payment. A replacement bank account printed on the invoice cannot silently update the supplier master. Those would require separately defined operations and checks.
Extract a candidate, then establish identity
The model proposes invoice fields and line items with references to their source locations. Supplier matching then uses the available business identifiers and company context. A matching display name alone may be insufficient when several entities use similar names.
If the identity remains ambiguous, stop before writing. Creating a new supplier to avoid the ambiguity would change the promised operation. The same principle applies to missing purchase orders: this contract should not quietly become a non-PO invoice workflow.
Reconcile arithmetic and business context separately
Consider a line with quantity 3 and unit price 40. Its subtotal is 120. For this arithmetic example, a configured 10 percent tax rule gives a total of 132. If extraction reads the quantity as 8, the line values no longer reconcile and a verifier should report the inconsistency.
Arithmetic reconciliation does not establish that the ordered items were received. Purchase-order and receipt checks answer different questions: whether the items, quantities, and agreed terms support the draft bill. Their tolerances and applicability must come from a versioned business policy.
| Check | What it can establish |
|---|---|
| Required fields | The contract has the information it requires. |
| Totals reconcile | The selected arithmetic policy is satisfied. |
| Supplier identity | The intended existing supplier is established. |
| PO and receipt match | The defined purchasing evidence supports the bill. |
| Duplicate protection | The operation is not permitted to create another copy. |
Protect and confirm the draft creation
A duplicate query before the write is not sufficient under concurrency. The destination needs a reliable uniqueness or idempotency mechanism, or the integration must disclose that limitation. The same operation identity should survive a lost response.
After creation, read the saved bill through an authoritative path and compare the supplier, amount, currency, company, and draft state with the intended values. If the response is uncertain, reconcile that operation before another write. A new model attempt cannot establish whether the first draft exists.
Return a receipt that stops at the same boundary
The receipt should identify the contract version, required check outcomes, policy and source references, operation identity, saved bill, and read-back evidence. Its completion state is draft confirmed. Any unavailable check or unresolved effect needs to remain visible.
Real invoice populations include credit notes, multiple orders, partial receipts, foreign exchange, and disputed amounts. Each introduces decisions about matching, permissions, and accounting policy. Define those extensions or separate contracts before expanding the workflow’s scope.
Missing a detail or found a problem?
Send a documentation question →