Reconciliation that closes before the team logs in

Matching a settlement file to an invoice ledger is genuinely mechanical work, which is why it is the strongest case for automation on this list. It is also money, which is why every exception stops at a person.

Book Enterprise DemoSee pricing

The situation

A finance team of three reconciles gateway settlements, marketplace remittances, and bank credits against an invoice ledger every morning. The work is arithmetic, but the exceptions are not: a short settlement might be a gateway fee, a partial refund, a TDS deduction, or an actual error, and only the last one matters. Most mornings are spent proving the first three.

  • Three people, two systems, every morning

    Vendor invoices arrive as PDFs and are rekeyed into both the accounting system and a tracking sheet. The same figure typed twice diverges eventually, and the divergence is found during audit rather than during the month.

  • Every settlement is short by design

    Gateway fees, GST on those fees, and TDS mean the credited amount almost never equals the invoiced amount. Without modelled tolerances, a matcher flags nearly everything, and a queue that flags everything gets ignored.

  • GSTIN and place-of-supply errors found late

    A vendor invoice with a wrong GSTIN or an inconsistent place of supply is only a problem at return-filing time, weeks after the payment cleared and the relationship moved on.

  • Adjustments without a reason

    A journal entry that squares a ₹1,840 difference is often written with no record of who decided it was a fee rather than an error. The number balances; the judgement behind it is gone.

The workflow

Every step names the control that applies to it. The steps marked Human are the points where the workflow stops and waits for a person — by design, not because the automation is incomplete.

Bank feed → AI → Approval → Tally ledger

  1. 01 / 07System

    Pull settlement, ledger, and bank data

    Fetches the gateway settlement report, marketplace remittance advice, and bank statement over read-only connectors at 06:00 IST, then loads open invoices from the accounting system. Nothing is written back at this stage.

    Read-only ingestion, no writes before matching

  2. 02 / 07System

    AI extracts fields from vendor PDFs

    Invoice number, date, taxable value, tax split, GSTIN, and place of supply are read from the document, each with a confidence. Low-confidence fields are marked for review rather than guessed, because a confidently wrong tax figure is worse than a flagged one.

    Per-field confidence; low confidence routes to review

  3. 03 / 07System

    Three-way match within modelled tolerances

    Matches on invoice reference first, then on amount-and-date within tolerance bands that model gateway fees, GST on fees, and TDS explicitly. A difference the bands explain is a match with a stated reason; anything else is an exception.

    Named tolerance bands, each difference attributed

  4. 04 / 07System

    Validate GSTIN and tax consistency

    Checks GSTIN format and checksum, confirms the place of supply agrees with the tax split, and verifies the taxable value plus tax equals the invoice total. Failures surface now, weeks before a return is filed.

    Checksum and internal-consistency validation

  5. 05 / 07Human

    Finance reviews the exception queue

    Only unmatched and low-confidence items reach a person, each with the candidate matches, the unexplained difference, and the tolerance bands already applied. Because the noise was attributed upstream, the queue is short enough to actually clear.

    Exceptions only; matched items need no review

  6. 06 / 07Human

    Controller signs off anything above threshold

    Adjustments above ₹2,00,000 require a second named approver, and every adjustment carries a typed reason from a fixed list. The reason is part of the record, not a free-text note nobody reads.

    Dual approval above threshold, reason from a fixed list

  7. 07 / 07System

    Post to the ledger with full lineage

    Writes matched entries and approved adjustments once, idempotently on settlement reference. Each posting links to its source rows, tolerance decision, approver, and reason, so the entry can be explained without reconstructing the morning.

    Idempotent posting, lineage on every entry

Controls

Step-level controls stop a single action. These apply to the workflow as a whole, which is what makes the difference between a logic error and an incident.

  • Nothing posts without an attributed difference

    Every rupee of variance is either explained by a named tolerance band or held as an exception. There is no path where the workflow squares a difference it cannot account for.

  • Low confidence is an outcome, not a guess

    Extraction confidence below the threshold routes the field to a human instead of substituting the model's best attempt. The failure mode of OCR on a tax figure is a wrong number that looks right.

  • Material adjustments need two people

    Above the threshold, the approver and the controller must be different named users. Segregation of duties is enforced by the workflow rather than by the org chart.

  • Postings are idempotent on settlement reference

    A replayed run cannot double-post. This is the same property the refund workflow relies on, for the same reason: retry safety has to be structural where money is involved.

The shape of the change

Each row states what the controls make possible or impossible, rather than a measured saving. The change is structural: the same work, with the risky path closed off.

  • Daily reconciliation window

    WasRekeyed by hand every morning

    Exceptions only, before login

  • GSTIN errors caught

    WasAt filing

    At ingestion

  • Adjustments without a recorded reason

    WasCommon

    Structurally impossible

Other workflows

The same controls apply across every use case. Only the steps and the thresholds change.