Paisa · What it does
Product · Bank reconciliation

Matched on evidence, or not at all.

Three tiers of matching, best evidence first. There is no fuzzy amount matching, because a line that is one rupee different from a ledger entry is a discrepancy to investigate — not a match to assume.

Implemented in src/erp/reconciliation.ts, src/banking.ts
Zerothe difference a reconciliation must reach to be signed off
Why it is built this way

3 decisions that carry the weight.

Deterministic matching

Exact amount and date, then exact amount within a settlement window, then exact amount plus a shared reference token. Anything left is shown to a person.

The identity is checked

Statement balance, plus deposits in transit, minus outstanding payments, must equal the book balance. That identity is verified, not asserted.

Cannot be signed off while out

A reconciliation with a non-zero difference refuses to complete, and an incomplete reconciliation blocks the close.

Capabilities

What it does, in full.

Statement import

Lines arrive from a bank feed or a file through the same idempotent path, so a replayed import creates nothing.

Outstanding items

Deposits in transit and uncleared payments are classified and totalled rather than lumped into an unexplained difference.

Review queue

A line the rules cannot categorise goes to a human queue. Paisa never guesses an account to make a number tidy.

Keyword categorisation

Recognised descriptions post automatically to their account; everything else waits. The assistant can draft a categorisation, but posting needs approval.

Duplicate detection

Imported lines are deduplicated by reference before they can reach the journal.

Close integration

Every cash account must carry a completed reconciliation as of the period end before the period can lock.

Related

Works with

See it against a real ledger.

The demo runs on a seeded company with a live close waiting — two real blockers and agents holding proposals.