Financial anomaly detection: catch costly errors early
A deterministic needs-attention feed that flags duplicate payments, outliers, missing docs and flagged counterparties — ranked for a human.
Reconciliation is the quiet job that decides whether your books are trustworthy. Every other number — profit, VAT owed, cash position — rests on the assumption that what is in the ledger matches what actually moved through the bank. When reconciliation is done late, in a spreadsheet, once a month, that assumption quietly stops being true. This is how FINMOZG turns reconciliation into a continuous, evidence-backed process instead of a month-end scramble.
The shape of itPull every transaction in automatically, let the Bookkeeper Agent classify each line with a confidence score and an evidence link, match payments to their documents, flag duplicates and missing paperwork, and turn your recurring patterns into rules — so the ledger is reconciled and ready to close, not waiting to be rebuilt.
Reconciliation is where most books break
In a typical small business the bank statement and the bookkeeping live apart for most of the month. Payments go out, money comes in, invoices arrive by email, and nobody reconciles until someone has to. By then the context is gone: which transfer paid which invoice, why there are two charges from the same supplier, where the receipt for that card payment went. The reconciliation becomes archaeology.
The cost is not just time. Unreconciled books hide duplicate payments, missing tax documents and misclassified expenses — the exact errors that distort a VAT return or a profit figure. Automating reconciliation is less about speed and more about never letting that gap open in the first place. It is the backbone of how AI bookkeeping works end to end.
Getting the data in
Nothing reconciles until the transactions arrive, and they have to arrive without manual export-import cycles. FINMOZG pulls them in two ways, and treats both as first-class.
- Bank API feeds. ПриватБанк and Монобанк connect through their API, so transactions stream in continuously — date, amount, counterparty, purpose and identifiers — the moment they post. There is no monthly download ritual and no stale data.
- Tolerant CSV import. For an account without an API connection, a tolerant statement parser reads a downloaded CSV. "Tolerant" matters: real bank exports vary in column order, date format, decimal separator and encoding, and the parser is built to absorb that variation rather than reject the file.
Documents arrive alongside the transactions — invoices, acts and receipts by email-in, upload or a connected store — so each line has something to be matched against. The two streams meet in a single reconciliation feed.
Classification with confidence and evidence
Once a line is in, the Bookkeeper Agent proposes what it is: which account it belongs to and the full journal entry. It draws on the counterparty history, the matched document, your chart of accounts and any rules you have already set. A recurring transfer to a known supplier with an invoice attached is an easy call; a first-time counterparty with a vague purpose line is not.
That difference is made explicit. Every proposal carries a confidence score and an evidence link back to the source document the classification rests on. The score is not decoration — it decides what happens next. Lines where the agent is confident and the match is clean auto-post to the ledger; lines below your threshold route to a human review queue, with the document and the reason for hesitation attached. You review what is worth reviewing, not everything.
Matching, duplicates and missing documents
A classified line is still incomplete until it is tied to its evidence. Matching links each transaction to its supporting document and checks that the two agree — does the bank amount match the invoice, net of fees and partial payments. In the process the engine does the checking a careful bookkeeper does at month-end, continuously instead, and routes anything off into the needs-attention feed.
- Duplicate detection. The same invoice forwarded twice, or a payment that hit the account twice, is flagged rather than booked twice — one of the most common and most expensive reconciliation errors.
- Missing-document detection. A payment with no matching invoice, or an invoice with no payment, is surfaced as an open item so nothing sits unsupported in the ledger and no tax document goes quietly missing.
- Partial and split matches. One payment covering several invoices, or one invoice settled in instalments, is reconciled correctly instead of being forced into a one-to-one match that would never tie out.
Rules that learn your patterns
Most of a business's transactions are not unique — they repeat. The same landlord, the same SaaS subscriptions, the same payroll provider, the same handful of recurring suppliers. FINMOZG turns those patterns into rules so the same decision is not asked twice.
When you correct a classification in the review queue — change the account, split the line, point it at the right cost centre — you can turn that correction into a rule. From then on, the matching counterparty or pattern is handled automatically on import. The feed gets quieter over time as your real-world structure is encoded into rules, and the review queue narrows to genuinely new or ambiguous activity. The agent learns from a decision rather than repeating the question.
Reconciliation as the gate to close
Reconciliation is not an end in itself; it is the precondition for a clean close. A period cannot be honestly closed while there are unmatched payments, duplicate charges or invoices without evidence sitting in the feed. FINMOZG treats a reconciled feed as the gate: the needs-attention items are resolved first, and only a ledger that ties out goes forward into the closing entries.
That is why reconciliation feeds straight into automating the month-end close. By the time the close runs, the heavy lifting is already done — every line classified, matched and evidenced — so closing becomes a deliberate, approved act rather than a reconstruction of a month nobody kept up with. As with everything in the platform, the critical actions stay under human approval.
FINMOZG is built Ukraine-first, which is why ПриватБанк and Монобанк are first-class connections and the terminology and tax handling match how Ukrainian businesses actually operate — see the Ukraine page for the local detail, or the product for how reconciliation fits the wider autonomous finance department. If clean, continuous reconciliation is what your books have been missing, that is exactly what this is built to deliver.