Choose invoice intake as the first boundary
For a hypothetical Philippine distributor, the first release could turn incoming supplier invoices into proposed payables records for a finance clerk. It would not select tax treatment, change supplier bank details or release money. This narrow boundary makes the handoff measurable: can the clerk accept a complete, traceable record with less rekeying and manageable correction work?
The design below is Kooya’s recommended operating method, not a reported customer deployment or a guarantee of savings. It addresses incoming-document processing. Building a system that issues compliant invoices or transmits tax data is a separate scope with its own requirements.
- Pick a small set of recurring suppliers and document types.
- Name the finance owner who can accept or reject the proposed record.
- List the fields needed by the destination system before choosing a model.
- Keep the existing manual intake path available for documents outside scope.
Classify the document before reading its fields
The BIR’s digest of RMC No. 77-2024 explains the invoice’s role as primary evidence for recording sales of goods and services and distinguishes supplementary receipts. That distinction matters to intake: a document showing payment is not automatically the same record as the invoice for the sale.[1]
Have the finance owner define the supported document classes and review ambiguous or converted forms. Do not turn a model’s label into a tax-compliance verdict. This guide does not provide a complete current invoice checklist or electronic-invoicing deadline; the owner should maintain applicable accounting and tax rules separately.
In the distributor example, a supplier might send an invoice, a later statement and a payment acknowledgment for the same transaction. Preserve their relationships rather than creating a new payable for each attachment. A filename containing “invoice” is only a clue.
Extract a proposed record with its evidence
Microsoft’s Document Intelligence invoice model illustrates the extraction layer: it analyzes documents and returns key fields and line items. This is an example of available tooling, not a recommendation that one model will handle every Philippine supplier layout.[2]
For the first workflow, agree a schema such as supplier identity, invoice number, invoice date, currency, line items and total. Preserve the original wording alongside normalized values. If a field is absent or unreadable, return that state; do not complete it from a plausible pattern.
Give the reviewer a source-page link or highlighted region for consequential fields. Separate the value read from the document from a value matched to your supplier master. A supplier name that looks similar is not enough to establish that the record belongs to the right legal entity or branch.
- Retain the original file and a stable intake identifier.
- Record extraction version, processing time and the destination record identifier.
- Show original and corrected values together with the reviewer’s reason.
- Keep a missing value distinct from zero, an empty string or a guessed value.
Use deterministic checks around the model
Kooya recommends ordinary software rules for checks that have precise answers. Recalculate amounts according to the finance-approved schema, verify required fields and compare identifiers with trusted records. Do not ask a generative model to improvise the company’s accounting rules.
Build a duplicate candidate check using more than one signal, such as supplier identifier, invoice number, amount and date. Send near-matches to review; invoice-number formatting can vary, and a corrected document may resemble an earlier submission. Keep a durable mapping so retrying an integration does not create another payable.
Where the process uses purchase orders and receiving records, compare the proposed invoice with those records and expose mismatches. An exact arithmetic match does not establish that goods were received or that the transaction was authorized. Treat each check as a distinct piece of evidence.
Calibrate review routing on your documents
Microsoft’s October 14, 2026 engineering article distinguishes evidence grounding from confidence and recommends evaluating confidence against checked examples for each field and document type. It cautions that a threshold does not transfer automatically across sources, configurations or model versions. Its reported customer results are not Kooya results or expected savings for your team.[3]
For this intake workflow, begin with finance review of every proposed record. Collect corrected examples and use a held-back set to evaluate any later reduction in review. Give missing critical fields and unsupported document types their own route. A high-confidence total should not make an unknown supplier acceptable.
Choose release conditions according to the consequence of an error. The reference number, currency and total may need different checks from a description used only for search. Keep records in review when the evidence does not support a dependable routing rule; there is no universal confidence cutoff in this guide.
Design the exception queue as a working product
An exception needs a reason, an owner and a next action. Distinguish unreadable images, missing purchase-order references, suspected duplicates, unknown suppliers and mismatched amounts. The reviewer should not have to infer the problem from a generic failure label.
For a blurred invoice, request a clearer copy and preserve the relationship to the first submission. For a supplier mismatch, route to the team responsible for master data. For a total mismatch, show the source and reconciliation details. Record the resolution before sending the proposed record onward.
Keep supplier bank-detail changes outside automatic document extraction updates. A document may contain new payment instructions, but their appearance on a page is not authority to overwrite trusted payment data. Use the organization’s established independent verification and approval process.
Protect the document across its entire route
Before using operational files, map where originals, extracted values, logs and review screenshots are stored and who can access them. Supplier documents may contain personal or confidential information. Have the responsible privacy and security owners approve the specific data flow, provider terms and retention arrangements.
Avoid copying complete invoices into general-purpose logs or support tickets when a record identifier and error code will do. A deletion or access change should cover the relevant derived records as well as the intake folder. Confirm how reviewers see only the documents assigned to their role.
The automation should fail visibly if its destination system is unavailable. Keep a pending state, retry safely and reconcile delivery acknowledgments. A successful extraction is not the same as a successfully accepted finance record.
Measure accepted records rather than pages read
Run the proposed workflow beside the current process on representative documents. Record accepted records, corrections by field, duplicate candidates resolved, documents returned to suppliers and total reviewer effort. Include integration failures and time spent finding evidence. Report which suppliers and layouts were tested.
A useful review meeting asks whether finance receives better records without losing control. If a new supplier format creates repeated errors, narrow the scope or add review rather than hiding the problem inside an average success rate. Recheck after changes to document layouts, extraction settings or destination fields.
Expand only when the owner can explain the remaining errors, operate the exception queue and reconcile records end to end. The practical deliverable is a dependable intake service with a clear handoff—not a demonstration that reads one clean PDF.
Use the AI pilot evaluation checklist to document the acceptance criteria and rollout decision.