Modeling receipt and invoice exceptions in the SIEMA prototype

The SIEMA purchasing prototype keeps ordered, delivered, accepted, damaged and invoiced quantities separate. Its comparison rule returns a status, discrepancy codes, an invoice-hold flag and a visible difference. That separation makes the review state explainable.

The rule boundary

The prototype checks short or over delivery against the order, damaged goods, delivery-note mismatch, and invoices above or below accepted quantity. A case becomes ready for finance only when delivered, accepted and invoiced quantities are present and no discrepancy remains. If an invoice exists before that state, invoiceHold is true.

The receipt validator accepts whole non-negative quantities and prevents accepted units from exceeding received minus damaged units. These are deterministic guards, not an OCR or AI judgment. The operator still decides what to do with a mismatch.

One scenario

Suppose the order is 100, delivery says 100, receiving accepts 92 and records 8 damaged, while the invoice bills 100. The rules flag a short delivery against the original order, damaged goods and an invoice above accepted quantity. The system can show a difference of 8 units and hold the invoice. It cannot decide whether to request replacement, a credit or a corrected invoice.

Events and evidence

The prototype stores a case, documents, a receipt and recent events. Document evidence is retrieved through signed storage URLs. This supports a visible sequence of what arrived and what was recorded. For a production workflow, access control, tenancy, audit completeness, retention and failure recovery would need separate validation.

What this prototype proves and does not prove

The code demonstrates explicit state transitions and human review of a prepared purchasing scenario. It is not evidence of customer ROI, automated accounting compliance or production readiness. A controlled pilot would need representative real cases, acceptance tests and named financial approval rules.

For a buying decision, see the Kaliits purchasing mismatch offer. This note records the implementation decisions; the Kaliits page explains the controlled pilot and how to request a diagnostic.