Why Bank Sync Drops Transactions (And How Non-Destructive Reconciliation Fixes It)
Published 28 August 2026 · 7 min read · Monairo team
You logged a coffee. Your bank also reported the coffee. Your budgeting app now shows either two coffees or none — and you have no way to tell which row it threw away.
This is the least discussed failure in personal finance apps, and it is the one that destroys trust fastest. A budget you cannot trust is worse than no budget, because you act on it.
Where the rows actually go
Automatic bank sync is not a live feed of your account. It is a series of point-in-time fetches through an aggregator (Plaid in the US, TrueLayer in the UK and EU), and each stage can lose or distort a row.
| Stage | What breaks | Result in your ledger |
|---|---|---|
| Pending to posted | A pending charge posts with a different amount or date, sometimes a different ID | Duplicate row, or an amount that silently changes under you |
| Token expiry | The bank consent lapses (often every 90 days under open banking rules) | A silent gap in history until someone re-authenticates |
| Re-delivery | The provider re-sends a window of transactions after an outage | The same purchase arrives two or three times |
| Merchant renaming | SQ *BLUE BOTTLE becomes Blue Bottle Coffee between fetches | Matching fails, so a duplicate is created |
| Backfill windows | The app only fetches N days back on first link | Everything before the link date is simply absent |
| Manual overlap | You logged it by voice; the bank reports it two days later | Double-counted budget unless the two are matched |
Note how many of these produce a duplicate rather than a loss. That matters, because the way most apps handle duplicates is what causes the actual loss.
The destructive fix, and why it is the wrong one
The standard approach is: detect a probable duplicate, delete one row. It is simple, it makes the list look right, and it is unrecoverable.
Three things go wrong:
- False positives are permanent. Two genuine same-day purchases at the same merchant for the same amount — a daily coffee, two transit fares — look exactly like a duplicate to a naive matcher. Delete one and you have quietly under-counted your budget, with no record that it happened.
- You cannot audit it. Once the row is gone, "why is my grocery total off by €14?" has no answer anywhere in the app.
- The wrong row can win. The deleted row may be the one carrying your category, note, receipt, or split — all of which vanish with it.
A ledger's job is to be the record. An app that edits the record destructively is not a ledger; it is a summary that occasionally lies.
Non-destructive reconciliation, concretely
Monairo takes the opposite stance: nothing in the ledger is ever hard-deleted. Removal is a soft delete, and duplicates are resolved by grouping, not by deletion.
1. Score candidate pairs. Rows within the same household are compared inside a time window (roughly ±48 hours) on normalized merchant name similarity, amount proximity, and time distance. Merchant strings are normalized first, so SQ *BLUE BOTTLE and Blue Bottle Coffee can still match.
2. Refuse to merge same-source pairs. Two rows from the same bank connection are never merged with each other — the provider already deduplicated those, so a second row with a distinct provider ID is a distinct real purchase. Likewise, two manual entries by the same person are never merged. This is the guard that protects your second coffee of the day. Cross-source pairs — a voice entry and the bank row for the same purchase — still merge, which is the case that actually needs solving.
3. Group and elect, do not delete. Matching rows join a reconciliation group with one elected canonical row. Budgets and analytics count the canonical row once. The other rows stay in the database, marked as suppressed, with the group and the score that produced the decision.
4. Keep it reversible. Because every source row survives, a wrong election can be reviewed and undone. The review screen surfaces the pairs the matcher was unsure about instead of silently resolving them.
The trade-off is honest: this design stores more rows and needs a review surface. In exchange, no purchase is ever destroyed by an automated guess.
Checklist: evaluating any app's bank sync
Before trusting a tracker with your history, ask:
- When it detects a duplicate, does it delete a row, or keep both and mark one?
- Can you see why two rows were considered the same, and reverse it?
- Does it merge a manual entry with the matching bank row, or leave you to do it?
- How far back does it backfill on first connection, and can it fill a gap after a token lapse?
- Does it treat inflows as income rather than negative spending, so your category totals are not distorted?
- Are amounts stored as integers in minor units, or as floating-point numbers that accumulate rounding error?
That last one sounds pedantic and is not: money held as a float drifts. Monairo stores every amount as an integer number of minor units end to end, so a total is exact rather than approximately exact.
For how this plays out against the mainstream alternatives, see Monairo vs YNAB vs Monarch. If you share a ledger with a partner, duplicates arrive twice as often — tracking shared expenses as a couple covers that case. Or just try Monairo on iOS or Android.
Frequently Asked Questions
Why does my budgeting app show the same transaction twice?
Usually because the pending version and the posted version of a charge arrived as separate rows, or because the provider re-delivered a window of transactions after an outage. Apps that match only on exact merchant and amount miss these.
Is it safe for an app to delete duplicate transactions automatically?
Not if the deletion is permanent. Duplicate detection is probabilistic, so any automatic rule will occasionally merge two genuine purchases. The safe pattern is to keep every row and mark one as canonical, so a wrong decision can be reversed.
How does Monairo decide which transaction is canonical?
Candidate pairs are scored on normalized merchant similarity, amount proximity, and time distance within a bounded window, and one row is elected canonical for that group. Rows from the same bank connection, or two manual entries by the same person, are excluded from merging entirely.
Do I lose data when my bank connection expires?
You lose new incoming rows until the connection is re-authenticated; existing history is untouched. Because Monairo never hard-deletes, re-linking fills the gap rather than replacing your ledger.
Does Monairo support banks outside the US?
Yes. Monairo uses Plaid for US institutions and TrueLayer for UK and EU institutions, and both ingestion paths converge on the same reconciliation logic.