Skip to content
Implementa.

Solution · By problem

Squaring the bank isn’t a month-end job: it’s matching every movement to its invoice, and that gets automated

Reconciliation doesn’t eat your time because of volume. It eats it on the awkward cases: the customer who pays four invoices in one transfer, the one who pays with no reference at all, the fee nobody saw coming, the returned direct debit. We build the circuit that matches the obvious on its own —which is most of it— and leaves you a short queue of exceptions with the context already pulled. Not another treasury tool: the matching work itself, done on top of your books.

The problem

The statement and the ledger tell different stories, and finding out why is detective work by hand.

  • Someone downloads the statement, opens it next to the ledger and works down it line by line ticking off what matches. Every month, from scratch.
  • One payment covers five invoices, or one invoice arrives in two installments: one-to-one matching is useless and it gets settled by eye.
  • Transfers land with no usable description —a reference that means nothing, an order number, the name of a person who isn’t the customer— and someone has to guess whose they are.
  • Fees, interest and returned debits show up at the bank with no document behind them, and they sit there until someone decides where they go.
  • The gap gets found at close, when there’s already no time, and retracing it to the guilty movement costs more than the difference itself.

Cost of staying the same

Squaring the bank by hand never shows up on an invoice: it shows up as a close that always lands late, as a cash position nobody trusts until it’s reconciled, and as receivables chased twice —or never— because the payment was sitting there unidentified. It’s the work you notice most the week the person who knew how to do it is out.

The solution

A circuit that matches the obvious, proposes the doubtful and only escalates what genuinely needs judgment

  1. 1We pull the statement in without anyone downloading it: through your bank’s API where it’s available, or through the standard statement file your bank already generates.
  2. 2We match every movement against your open invoices, payments and entries — not just on amount and date, but on reference, description patterns, that customer’s history, and on combinations: one deposit covering several invoices, or one invoice paid in installments.
  3. 3Payments with no reference get identified from what they do carry: the originator, the amount against what that customer has outstanding, and how they usually pay. If the proposal is solid it gets applied; if there are two plausible candidates, nothing gets invented — it escalates with both and the reasoning.
  4. 4Anything with no document behind it —fees, interest, reversals— gets coded to its account by rule, and whatever falls outside the pattern gets flagged instead of slipping through.
  5. 5We leave it measured with an explicit boundary: what share matches untouched, how many exceptions are left and of what kind, and how much the time-to-squared drops. Autonomy gets released per movement type once the accuracy earns it, not before.

What changes

What you stop losing

  • The statement doesn’t need downloading: standard bank statement formats mean one circuit reads accounts across different banks without building an integration per institution.

    Standard statement formats (Spain: Norma 43 / AEB) · checked 17 Sep 2026

  • And that plumbing isn’t about to expire: European banking is migrating to ISO 20022 (camt.053) progressively, with legacy national formats coexisting alongside it for years. The circuit is built to read both.

    SWIFT/European banking migration to camt.053, 2026-2028 window · checked 17 Sep 2026

  • No borrowed numbers: we don’t publish a generic match rate, because it depends on your data —on whether your customers add a reference and how many payments arrive lumped together. What we do is measure it on your own history before you decide, with your real movements.

  • What we measure: % of movements matched with no intervention, open exceptions by type (no reference, lumped, partial, no document), how often the proposal is right when a person reviews it, and days from the movement to a squared bank.

    What we measure

Spec sheet

Work it removes
working down the statement line by line beside the ledger matching movements by hand, and chasing down whose each unreferenced payment is
Typical setup
2–4 weeks
Input
your account statements (bank file or API) plus your open invoices, payments and entries
Output
movements matched and posted, the doubtful ones escalated with a proposal and a reason, and the gap located before close
Works with
SageHoldedOdooA3SAP
Can connect to
Your bank’s standard statement file, or its APIYour open invoice and receivables ledgerYour chart of accounts and your rules for fees and interest
What we measure
% of movements matched with no interventionopen exceptions by type (no reference, lumped, partial, no document)how often the proposal is right when a person reviews itdays from the movement to a squared bank
Good fit for
companies with daily movement volume and a ledger of open invoices and receivables to match against, even when the bank descriptions come in dirty
Not a fit for
the accounting judgment of the close, the call on what gets provisioned or written off, and signing the accounts: that stays with your team. And if what you want isn’t a squared bank but the whole bookkeeping role —invoices, entries, collections— that’s agente-contable-ia, not this page

See everything you can automate in Finance and accounting

Frequently asked questions

No, and the difference matters before you buy anything. This page is one specific job: the bank one. The statement comes in, it gets matched against invoices and entries, unreferenced payments get identified, the gap gets closed. That’s all. The full bookkeeping role —capturing the invoice that arrives, extracting its data, proposing the account and cost center, posting, reconciling and chasing what’s overdue— is the AI accounting agent, where reconciliation is one of its pieces. If your pain is the month that disappears into squaring the bank, start here; if it’s that the entire accounting back-office runs by hand, start with the agent and this sits inside it.

That’s the case that breaks most automatic reconciliation, because nearly all of it pairs one-to-one on an exact amount. Here it looks for the combination: given a deposit, it tests it against the sets of that customer’s open invoices that sum to the amount —including the possibility that it arrives with an early-payment discount or a withholding—; given an invoice, it accepts that several movements cover it and leaves it open as partial until the rest arrives, rather than calling it paid or calling it a discrepancy. When more than one combination fits equally well, it doesn’t pick at random: it escalates with both options, because a match that’s right by luck dirties the ledger and surfaces three months later.

Nothing explicit, but there are signals, and in most cases they’re enough. The movement carries an originator, an amount, a date and a description, however dirty. Against that we cross what that customer has outstanding, how they’ve paid historically —whether they round, whether they lump, whether they pay at 30 or 60 days— and the variants of their name, which is what fails most by hand: the payment comes in under a holding company, a director, or a trading name that doesn’t match the record. What we don’t do is force an assignment to keep the scoreboard clean: if the signal is weak, the movement stays identified as pending with its candidates, which is useful information, rather than falsely reconciled, which is an error someone pays for at close.

No. This is built on what you already use: the statement comes in through your bank’s file or API and the result gets written into your accounting (Sage, Holded, Odoo, SAP and similar). If you already have a treasury tool you like, we connect it rather than replace it; what we automate is what that tool doesn’t do —match the awkward cases against your real ledger and escalate with context instead of leaving a list of “unreconciled”. What we remove is the step where a person downloads the statement and ticks off lines.

It’s designed assuming it will, because in reconciliation the silent error is the expensive one. Three things contain it. It starts in proposal mode: it matches, but a person approves, and autonomy gets released per movement type only once the measured accuracy earns it. Everything it applies leaves a trail —which movement, against which document, by which rule or signal— so reverting is one step, not an investigation. And the confidence threshold is yours: below it, it escalates instead of deciding. The honest comparison isn’t against a perfect process: it’s against squaring by hand at nine at night on the 3rd, which also gets things wrong and leaves no record of why it ticked that line.

Want it running in your business?

You’ve pinned the problem. We ship the fix and leave it measured.

See the service
Squaring the bank isn’t a month-end job: it’s matching every movement to its invoice, and that gets automated · Implementa