I went to SIEMA confident about the problem I wanted to work on: compare a purchase order, a delivery note and an invoice, then make discrepancies visible.
The logic makes sense on a screen. A company orders something, receives something, and gets billed for something. When those records disagree, somebody needs to look closer.
In the Instagram video I recorded around the event, I talked about the part that complicated that confidence. A conversation moved the problem beyond reading documents and comparing numbers. It raised the question of what evidence makes a claim about the physical delivery trustworthy.
The demo was only part of the problem
OCR can help read a quantity from a document. Matching can show that two quantities disagree. Neither step observes what actually arrived.
That distinction sounds obvious when I write it down. It becomes more important when the whole product idea is built around detecting a mismatch.
The document might be readable. The calculation might be correct. The disputed fact might still be somewhere outside the software.
Ordered, delivered, recorded, accepted
I now want to separate those words more carefully.
Ordered is what the buyer requested. Delivered is a claim about what physically arrived. Recorded is what somebody entered or wrote down. Accepted is what the receiving process agreed to recognize.
Those values may coincide. When they do not, displaying a warning does not resolve the disagreement. The next question is which evidence supports each value, who recorded it and who can decide what happens next.
This is the part of the SIEMA conversation I want to keep exploring. If the supplier disputes a receiving record, what makes that record credible? Is another measurement, a documented procedure or independent verification needed in that particular workflow?
Those are questions about how the work happens. I cannot answer them by choosing a better OCR model.
A simple example, with a limit
Imagine an order for 20 units, a receiving record for 17, and an invoice for 20. This is an illustrative example, not a measured customer outcome.
A system can compare the records and flag three units for review. That is useful.
But if the supplier says all 20 were delivered, the comparison alone cannot establish what happened. Someone needs evidence from the receiving process. The software can organize that evidence and retain the decision. It cannot manufacture the missing proof.
A demo can show that an exception path works. It cannot establish that everyone involved will accept the inputs as trustworthy.
The same mismatch can mean different things
The video also raises the difference between local and international supplier relationships. I do not take one conversation as a rule for either market.
It is a reason to ask more specific questions. What does the existing agreement require? How is receipt documented? Who can raise a dispute? What would the other party accept as evidence?
A familiar spreadsheet, a signed receipt or an existing ERP process might already cover an important part of this. Before adding a new tool, I want to understand where that process actually stops helping.
I want to leave room to change my mind
I still think document comparison is useful. What changed was the boundary of the problem.
Instead of only asking whether I can detect a discrepancy, I need to ask whether I can help a person resolve it with evidence that the process recognizes.
That is the kind of thing I want to share here. An idea, a demo, a conversation, and the point where reality makes the idea less tidy.
I do not want every post to sound like a finished conclusion. Sometimes the useful thing to publish is the question that interrupted my confidence.
Watch the original and follow the technical thread
Watch my SIEMA video on Instagram
How the SIEMA prototype models receipt and invoice exceptions
If you want to work together on a document workflow, commercial conversations go through Kaliits.