VapusData logoVapusData logoFin
← All solutions

Solutions

Every invoice checked before it becomes a record

Invoices captured from upload or a scheduled feed, validated before ingestion, matched n-way against header and expected data, categorised by reason when they do not agree, and released only once a checker has approved them.

Book a demo
Validation before ingestionN-way matchingMaker-checker before export
Payables
RetailManufacturingLogisticsOCR & extractionN-way matchingAgentic workflowERP write-backAudit trail
01

The challenge

A national value retail chain runs invoice and header reconciliation across several entities. Invoices arrive by upload and by scheduled feed, in formats that vary by vendor, and each one has to be checked against header and expected data before it is fit to be a record in the ledger. Done by hand, the checks are inconsistent between reviewers, the reasons invoices fail are not counted anywhere, and duplicates are found late — after a second copy of the same invoice has already been keyed. The requirement was a single path from capture to export in which every check is recorded and a person still approves what leaves.

02

What we built

One flow from capture to export. Invoices arrive by manual upload or on a schedule from SFTP or a configured data source, and OCR reads invoice number, vendor, amounts, tax, GSTIN and dates from each one. Mandatory-field, format and business-rule validation runs before ingestion rather than after it, with duplicates and warnings reported separately from hard failures. Line items are matched n-way against header and expected data, and every outcome is categorised as accepted, mismatched or incomplete with a reason bucket attached. TDS is tagged automatically and expense categories are mapped. Nothing exports until a checker has approved it.

03

The result

The reasons invoices fail become countable. GSTIN mismatch, amount mismatch and date mismatch are separate buckets rather than a single pile of exceptions, so the root cause is visible and a vendor sending the wrong registration number every month is identifiable as such. Duplicates are caught before ingestion instead of after keying. Filters and financial rules are configured by the finance team without engineering support. Maker-checker keeps a person on the release, and the field-level audit trail plus per-run process logs mean any figure in the export can be traced back to the document and the reviewer who approved it.

Process

How it works

Four stages, with the validation deliberately placed before ingestion — a record that should never have been created is harder to remove than one that was never created.

  1. 01

    Ingest & extract

    Invoices arrive by manual upload or on a schedule from SFTP or a configured data source. OCR reads invoice number, vendor, amounts, tax, GSTIN and dates from each document, and every run is logged with what it collected and what it produced.

  2. 02

    Validate

    Mandatory fields, formats and business rules are checked before ingestion. Duplicates and warnings are reported separately from hard failures, because a duplicate is a different action from a malformed field, and a warning that stops a batch is a warning nobody will read twice.

  3. 03

    Reconcile

    Invoice line items are matched n-way against header and expected data. Each outcome is categorised as accepted, mismatched or incomplete, and a mismatch carries its reason bucket — GSTIN, amount or date — so causes can be counted rather than described.

  4. 04

    Review & export

    A maker prepares, a checker approves, and only then does anything leave. Approved data exports to Excel with the applied filters intact, or writes back to the source location, and the audit trail records the field, the value, the approver and the run it belonged to.

What it does

Inside the solution

Capture from upload or a schedule

Invoices arrive by manual upload or on a schedule from SFTP or a configured data source, and OCR reads invoice number, vendor, amounts, tax, GSTIN and dates. One extraction path serves both, so an ad-hoc document is treated no differently from a scheduled batch.

Validation before ingestion

Mandatory fields, formats and business rules are checked before a record is created, not after. Duplicates and warnings are reported separately from hard failures, so a second copy of an invoice and a missing tax field are handled as the different problems they are.

N-way matching

Invoice line items are matched against header and expected data rather than against a total. Agreement at the header while the lines disagree is a common and expensive failure, and only a line-level comparison finds it.

Outcomes in reason buckets

Every result is accepted, mismatched or incomplete, and a mismatch carries its cause: GSTIN mismatch, amount mismatch, date mismatch. Counting by bucket turns an exception queue into a list of fixable upstream problems.

Filters and financial rules you configure

Reusable filters and the financial rules behind the checks are configured by the finance team without engineering support. A rule that requires a ticket to change is a rule that stops reflecting how the business actually pays.

TDS tagging and expense mapping

TDS is tagged automatically and expense categories are mapped from what the invoice describes, so the two decisions most often made from memory are made the same way each time and are visible in the record.

Maker-checker before anything leaves

A maker prepares and a checker approves. Approved data exports to Excel with the applied filters, or writes back to the source location. The control is on the release rather than on the reading, which is where it belongs.

Entities, access and audit

Multiple entities are scoped as separate domains with role-based access, and every change is captured in an immutable field-level audit trail alongside per-run process logs describing what each run collected, matched and exported.

Nearby

Related solutions

Payables

Physical invoice OCR & reconciliation

The paper-heavy path into AP: scanned, photographed and couriered invoices with no text layer, read with a confidence score on each field and validated exactly as a digital invoice is.

Details
Payables

Contract, PO & invoice reconciliation

Three-way agreement between what was contracted, what was ordered and what was invoiced — with the clause that governs each check cited back alongside the result.

Details
Payables

AP fraud detection

Vendor impersonation from lookalike domains, bank details changed at the last minute, and invoices that do not behave like the vendor's own history — held before the payment run and routed to a named approver.

Details

Foundations

The VapusFin models behind it

Accounts Payable Automation

Accounts Payable

Capture every invoice however it arrives, match it line by line against the PO and the goods receipt, and pay only what the contract says you owe.

Details
Employee Expense Claims

Expense Claims & Reimbursement

Employee-side out-of-pocket claims: checked against your policy, cross-read against the receipt, deduplicated across people and periods, and paid straight through when they comply.

Details

Questions

Frequently asked

Why validate before ingestion rather than after?
Because a record that should never have existed is harder to remove than one that was never created. Checking mandatory fields, formats and business rules first keeps the ledger clean, and the invoice is held with the failed check named so the vendor can be told what to correct.
How are duplicates handled?
They are detected at validation and reported separately from hard failures and from warnings. A duplicate is not a malformed invoice; it is the same invoice arriving twice, and it needs a different action from a different person.
What does n-way matching compare?
Invoice line items against header and expected data. Matching on totals alone accepts an invoice whose lines are wrong in offsetting directions, and that is precisely the case worth catching before payment.
Can our team change the rules without raising a ticket?
Yes. Reusable filters and financial rules are configuration, owned by the finance team. Changes are recorded, so a shift in acceptance rates can be traced back to the rule change that caused it.
Does anything reach the ERP without a person seeing it?
No. Maker-checker is mandatory: a maker prepares and a checker approves before export or write-back. What automation removes is the re-keying and the checking, not the accountability for what is released.
What outcome figures can you share?
None yet. The engagement is scoped and in delivery, and we do not publish a figure until it has been measured and agreed with the customer. Requirement targets are not achievements, and we do not present them as if they were.

Want the same outcome?

Send us a batch of your own invoices and expected data, and we will show you what would have been accepted, what would have been held and under which reason bucket, before you commit to anything.

Book a demo

Last reviewed

Cookie preferences

Essential cookies are required for the site to function and cannot be switched off. Everything else is off until you switch it on, and you can change or withdraw your choice at any time from the Cookie settings link in the footer. The Cookie Policy lists the cookies we set and how long each one lasts.

No choice recorded yet