The Evidence Graph: Why Context Matters More Than Data in Invoice Validation

A ₹4.2 lakh invoice from a regular vendor passes every check your AP system runs. Valid GSTIN. Correct IRN. No duplicate match. PO total within tolerance. Amount matches line items. Approval workflow completed. The invoice is paid. What the check did not run: the contract price schedule specifies ₹380 per unit for orders above 800 units. This invoice has 1,050 units at ₹400 per unit. The invoice is arithmetically correct and financially wrong. The overpayment is ₹21,000. That information lives in the contract. The check that would have found it requires the contract and the invoice to be in the same view at the same time.

Source, Signal, and Insight

A document is a source. The unit price on line 3 of an invoice is a signal — a piece of extracted data. The fact that this unit price is 5.3% above the contracted rate for this volume tier, and this is the fourth consecutive invoice from this vendor with the same pattern, is an insight.

Most AP tools stop at signals. They extract, they validate format, they check for duplicates, they compare against PO totals. The extracted signals are clean: GSTIN valid, IRN present, amounts add up. But signals in isolation have no context. A unit price is just a number. Whether that number represents correct billing, an honest mistake, or systematic overcharging only becomes clear when you compare it against the contracted rate — which is not on the invoice, it is in the contract.

The intelligence gap in AP is not in extraction. It is in the connection layer: what does this signal mean in relation to the other documents this transaction is attached to?

The Evidence Chain

Every invoice sits at the intersection of multiple documents. Purchase Order: the approved source of what was ordered, at what price, for what quantity. Goods Receipt Note: the confirmation of what was actually received. Contract: the legal record of what was agreed — unit rates, payment terms, SLA conditions, penalty clauses. Vendor Master: the historical record of this vendor's bank details, GSTIN, TDS section, and transaction history.

Each connection enables a different check:

Invoice + PO: quantity and price validation for this specific transaction. Catches overbilling and rate errors at the transaction level.

Invoice + GRN: delivery confirmation. Catches payment for goods not received and establishes the basis for short-delivery penalty calculation.

Invoice + Contract: clause-level compliance. Catches rate drift against contracted price schedules, payment term violations, and unenforced penalty obligations.

Invoice + Vendor History: behavioral baseline comparison. Catches template changes, bank detail drift, billing cycle anomalies, and repeat patterns of the same discrepancy type.

No single connection gives the complete picture. When all four connections are active simultaneously, the flags compound: a price discrepancy against the contract is a medium-priority flag. A price discrepancy plus a bank detail change plus an invoice that arrived outside the vendor's normal billing cycle is a high-severity combined signal that warrants holding the payment pending human review.

Why This Requires an Evidence Graph, Not a Checklist

A checklist validates fields against rules. An evidence graph validates a transaction against its full context. The difference is not just technical — it changes what you can find.

A checklist would catch a wrong GSTIN. An evidence graph catches that the unit rate on this invoice has drifted 12% from the contracted rate over the last nine months, across 47 invoices, while the vendor's GST filing regularity has declined and their invoice amounts have been growing faster than the contracted rate schedule allows.

The finance software industry has built very good filing cabinets — systems that organize financial data clearly and make it retrievable. The intelligence layer is the step beyond retrieval: understanding what the data means in relation to everything else you know.