Our summary
An invoice app needs to read unfamiliar company names and amounts, then match the invoice to a known property. Mariano Barcia explains why those are different jobs. His Java application keeps a text-generating model for reading the details and gives Jev the decisions with a fixed set of possible answers.
Jev answers two fixed-option questions together. One rates supplier evidence as explicit, strongly suggested or insufficient; the other picks a property from the supplied list. Ordinary code decides when to request image analysis. A person still confirms the recommendation, and separate application code handles archiving the invoice.
Picking an allowed property prevents an invented identifier, not a wrong match. The article describes an architecture rather than proving faster or more accurate invoice processing. Its useful boundary is that model judgments stay separate from human approval and external actions. The existing text model still extracts names, invoice numbers and amounts.
Key takeaways
- Separate reading new values from comparing known options. Extracting a company name is not the same as judging the evidence for it.
- Ask related questions together when they use the same invoice facts, while keeping the application's next steps in ordinary code.
- A valid selection is not necessarily correct. Keep human confirmation and external actions separate from the model's recommendation.