Pilot AP document matching for one construction site

Name the buying company, site, suppliers, document types and source systems. Specify whether the test includes goods invoices only or also services; mixing them can obscure different acceptance evidence. List the fields to extract, the order and receipt data available for matching, and the person who can accept a proposal.

For this pilot, the integration account reads approved purchase and receipt records and writes only to a staging queue. It cannot create invoices, release payments or change supplier bank details. Restrict document access to the chosen scope. Use approved test data or appropriately protected copies, and agree retention and deletion with the data owner before ingestion.

Set a fixed evaluation period and sample before tuning. Include ordinary invoices and a deliberately selected challenge set. The ordinary sample estimates operational usefulness; the challenge set probes known failure modes. Report them separately so a collection of easy documents cannot hide a serious control failure.

Consider a fictional supplier that sends invoice 417 to two buying companies. The scanned headings are similar, and both companies have an order for the same material. Matching on invoice number and supplier name would make one look like a duplicate or, worse, allocate it to the wrong entity.

The proposal must carry buying entity, supplier identity, invoice number and relevant date or series information, with links to the source. If the company cannot be established, route it for review. Do not select the company with the closest total. A candidate match is useful only when the reviewer can see why competing candidates were excluded.

Include a second challenge: an invoice for 100 units, 90 physically received, ten of those held. The proposal should expose 80 accepted, ten held and ten undelivered. It must not treat the whole receipt as accepted. Use the partial-receipt matching guide to agree the finance decision before evaluating the automation.

OCR reads text. A model may help interpret variable layouts and suggest invoice fields. Deterministic rules can validate formats, calculate line totals, compare units and check whether a referenced order exists. None of these steps establishes contractual acceptance by itself.

Microsoft's invoice extraction documentation describes extracting invoice fields and line items. Treat that as a capability to test on your documents, not proof that an invoice is payable. The review screen should show each important value beside its page evidence, preserve the original file and record the model or parser version used.

Use confidence to prioritise review only after checking its behaviour on the sample. A high score on an incorrectly recognised entity is more consequential than a low score on a harmless description. Define field-specific checks and an abstention route. Reviewers must be able to reject a proposal without inventing a replacement value.

Before the pilot, record active handling minutes, time waiting for evidence, queue age and the types of corrections AP makes. Use the same definitions during the trial. Median handling time describes the ordinary case; a higher percentile helps reveal difficult cases. Keep waiting time separate so an absent receipt is not reported as slow model processing.

Measure false matches, missed duplicates, reviewer corrections and proposals that require reopening. Track how many records were excluded and why. A result such as zero critical failures in a small challenge set is a release condition for that test, not a statistical guarantee about all future invoices.

Agree success thresholds with AP before viewing the results. For example, the pilot can require every proposed entity and receipt allocation in the challenge set to be correct or explicitly withheld. The business can set a handling-time target from its own baseline; there is no credible universal savings percentage to promise here.

A timeout does not prove that a request failed before being processed. Assign a stable submission identity and inspect the existing result before resubmitting. The AWS discussion of idempotent APIs explains why caller request identifiers and retry semantics matter. Your staging integration needs an explicit policy for the same identity arriving with changed content.

Test duplicate file delivery, a service timeout, a late response, a receipt amended after extraction and a reviewer opening a stale proposal. Revalidate the current source state before accepting a match. Preserve the original proposal and the reason for superseding it.

If the pilot performs an unauthorised write, associates a document with the wrong entity, or creates a duplicate downstream record, stop the affected automation. Quarantine pending proposals, retain logs and switch the team back to the documented manual process. Reconcile the full affected interval against the ERP before reopening the queue. Deleting a problematic row is not an adequate recovery record.

AP owns the operating result; finance approves treatment and permissions; IT owns integration recovery and access. Hold a review using the fixed sample, exception log and actual reviewer feedback. Identify whether poor performance came from extraction, source records, matching rules or the approval process. Each calls for a different fix.

Proceed only when the pilot has demonstrated a useful review queue and reliable recovery. A larger document volume may be the next step. Automated posting is a distinct scope change requiring new controls, tests and authority.

1. Select one site and supplier group, and document the read-only source access and staging permissions.
2. Freeze the baseline sample and challenge cases, including the two-company invoice collision.
3. Run AP review with source evidence and record corrections, abstentions and handling time.
4. Demonstrate stop, reconciliation and restart before deciding whether to expand.