Principles, Scenarios and Suitability
Invoice and payment-slip processing separates OCR, field extraction and actual transaction verification. Reading an amount or account number does not prove payment or document validity. Use authorised verification sources and accounting procedures.
OCR transcribes text; a field gives meaning, such as total, date or document number. Correct digits placed as a total when they describe a pre-tax amount are still wrong. An invoice requests payment; a slip image needs transaction confirmation from suitable sources. Separate reading, meaning extraction and actual money verification. Clear images establish neither authenticity nor successful transfer.
A schema defines agreed fields and data types. Arithmetic checks find some errors, but edited documents can also have consistent totals. Draft queues add review while reducing incorrect-posting risk. Staff need raw text and relevant crops with correction histories. Separate transcription from approval permissions; service accounts must not bypass business rules to create financial effects.
Scroll the diagram horizontally to inspect all details.
Illustrative Design Scenario
Illustrative design scenario: queue draft vendor, date, amount and tax fields for staff to check against original crops before approval. A slip may be flagged as a duplicate image, but images alone do not prove forgery or receipt of funds.
Hypothetical arithmetic, not a certified tax rate: pre-tax amount 1,000 plus tax 70 gives total 1,070. Read every field. If the total becomes 10,700, the equation can trigger a hold but must not automatically correct it to 1,070. Reviewers should inspect the original and confirm meanings, including potentially different currencies.
Repeated submissions should suggest similar images or duplicate codes for review, not allege fraud: resubmission may improve image quality. Link documents to confirmed transaction identifiers or reconcile before accounting entry. Use test data with personal information concealed, not actual postings or money transfers to demonstrate reading.
Inputs and Prerequisites
Prepare document types, field schemas, number and date formats, vendor codes and personal-data policies. Separate permissions for transcription, review and transaction approval.
Retain document type, date convention, currency, layout revision and raw text before adjustment. Minus signs and parentheses may have accounting meanings. Define them under the process rather than strip everything to digits.
Results should remain drafts with crop sources, quality and review status, including corrected values and editors. Restrict account images, names and vendor information by access and retention. More model data does not justify unnecessary disclosure.
Trial and Integration Workflow
- 1Check image quality and classify the document before extracting fields.
- 2Retain raw text and check arithmetic relationships between totals and tax.
- 3Require human approval and trusted transaction confirmation before actual posting.
Evaluation and Acceptance Criteria
Measure exact agreement by field and documents needing correction. Test magnitude errors, decimals, dates, duplicates and false duplicate alerts. Acceptance must distinguish OCR correctness from accounting checks and payment confirmation.
Exact match needs both correct value and correct semantic field. Test held-out layouts and ambiguous data. Aggregate character accuracy cannot substitute for correct amounts: one wrong digit may have substantial financial effects.
Accounting staff should trace images to draft values and approval. Test resubmission without duplicate transactions, with correction and challenge routes before live posting. Software acceptance does not certify documents or payments.
Scroll the diagram horizontally to inspect all details.
Failure Cases and Limitations
Images can be edited and layouts change. Correct arithmetic does not establish authenticity. Images alone provide neither findings of wrongdoing nor legal assurance. Require review and correction routes before financial effects occur.
Layout is field arrangement and varies by issuer. Similar field names need not share meanings. Review new document types; do not combine guesses with evidenced values without distinguishing status.
Future verification-source or ERP integration needs actual permission and API checks, not claims of all-bank verification services or legal certification. Protect people and trading partners when retaining images and corrections under the limited purpose.
Practical Checklist
- Are amounts read with complete signs and decimal positions?
- Are raw and corrected values separate and traceable?
- Is payment confirmation independent of the payment-slip image alone?