Automate hospital invoice matching at line level

A hospital orders 100 boxes, accepts 96 and receives an invoice for 100. An extraction tool reads the document correctly. If it sends the total straight to accounting, it has automated the wrong handover.

Hospital accounts payable automation should prepare an explainable match for finance review. It needs the approved purchase order, the relevant accepted receipt lines and the supplier invoice, with their units and revisions intact. Missing receipt evidence should remain missing rather than be inferred from the bill.

Work the difference at line level

Assume an illustrative price of ₹500 per box, excluding tax and other charges. The order value is ₹50,000. The accepted receipt supports 96 × ₹500 = ₹48,000 on this quantity basis. The remaining four invoiced boxes represent a ₹2,000 quantity difference requiring review.

The ₹48,000 figure is an illustrative match proposal, not permission to post or pay part of an invoice. The actual agreement and finance policy must determine taxes, tolerances and treatment of a disputed balance. Keep that commercial decision separate from the quantity calculation.

oeHealth's procurement documentation describes matching purchase orders, receipts and vendor bills. A hospital pilot should verify its own evidence requirements and correction path rather than inherit vendor defaults.

Make extraction reviewable

Capture supplier identity, invoice reference and date, currency, PO reference, line item, quoted unit, quantity, rate, charges and tax fields. Keep each extracted field linked to its document location. AI may suggest a supplier-item mapping; an authorised reviewer confirms ambiguous packs, unfamiliar item codes or conflicting amounts.

An invoice for ten packs cannot be compared with ten individual units until an approved conversion is available. Preserve the original unit and the conversion used. Recalculate line amounts separately from commercial rules so arithmetic errors do not become indistinguishable from disputed terms.

Route quantity questions to stores, contract or rate questions to procurement, and posting treatment to finance. Keep these tasks attached to the disputed line. A generic “mismatch” queue leaves AP rediscovering the owner each time.

Limit the first integration

The suggested first pilot covers only the agreed PO-backed invoice model. Leave non-PO and consignment transactions outside it until their evidence and liability rules have been separately established by finance and the contract owner.

Ask the ERP owner to demonstrate supported reads, the restricted destination action, source attachments, approval references and recovery before enabling writes. Begin with proposed matches only. The guide makes no claim that a particular ERP supports these controls without configuration or additional work.

The matching result prepares a decision. It is not a payment instruction, and an approval to post does not grant the integration permission to release funds.

Test repeated intake and uncertain posting

Use supplier identity and invoice-reference context alongside document identity to find likely duplicates. Do not assume a file hash alone catches a rescan or that an invoice number is unique across all suppliers. Preserve a review route for legitimate corrections and credit notes.

Test a partial receipt, invoice before receipt, changed pack, disputed charge, credit note, repeated upload and a posting timeout after the ERP has accepted the invoice. In the timeout case, establish the destination outcome before another creation attempt. During failure, hold the work in the AP queue; reconcile any authorised manual posting before resuming automation.

Acceptance requires no duplicate liability in the agreed challenge set, source evidence for every matched line and an owner for every mismatch. Measure extraction corrections, commercial exceptions and posting failures separately. Compare age and review effort with the same supplier scope before the pilot, without projecting unmeasured savings.

Retest the match when receipt evidence changes

Suppose the remaining four boxes later acquire valid acceptance evidence. The proposed match can then cover 100 boxes, but it must recognise the earlier 96 rather than add a second full 100-box receipt. Retain receipt-line identities and their accepted quantities; aggregate only the applicable, non-duplicated evidence. The revised match is a new reviewed result, not permission to overwrite a prior posting.

Run this matrix with AP and stores signing off their own evidence. Report the proportion of eligible invoice lines needing extraction correction separately from lines needing a commercial decision; keep missing-source cases in the denominator or report their exclusion explicitly. During a read-only stage, compare proposed results with independently reviewed decisions. Permit writes only after the ERP owner proves the posting and recovery behaviour.

The scope ends with an approved accounting handover. It does not include bank payment release or supplier-master changes. That limit keeps the pilot focused on making each payable decision traceable.

Next actions

1. Agree the accepted-receipt basis and finance treatment for disputed lines.
2. Build a synthetic invoice set containing partial, duplicate and corrected cases.
3. Enable controlled posting only after AP approval and demonstrated ERP recovery.

Topics: hospital accounts payable automation · hospital invoice automation · hospital three way matching · hospital GRN invoice matching