The path a transaction takes
From a connected feed or an uploaded statement file. Nothing is posted at this point.
A staging area at /accounting/transactions. This is the buffer that makes everything else recoverable.
If you have written a rule that matches, it is categorised deterministically and no one is asked.
An agent suggests a category with a confidence. You accept, change it, or write a rule so it never asks again.
As a journal entry, with the bank account on one side and the category on the other.
Matching the posting to the invoice or bill it settles. See Reconciliation.
Transactions
Bank — current · 42 to review
| Date | Description | Amount | Suggested | Source |
|---|---|---|---|---|
| 12 Mar | STRIPE PAYOUT | +2,481.20 | Card settlement | Rule |
| 12 Mar | AWS EMEA | −418.55 | Hosting | Rule |
| 11 Mar | HARBOUR LOGISTICS | +8,400.00 | Invoice INV-1042 | Match 96% |
| 11 Mar | BP CONNECT SW11 | −72.40 | Motor expenses | AI 71% |
| 10 Mar | TFR REF 88213 | −1,000.00 | Unclear | None |
The five ways a feed double-counts
Every one of these has happened to somebody, and each produces a ledger that looks plausible and is wrong. They are worth reading once before you connect anything.
- Feed plus file. A connected feed and an uploaded statement covering the same dates. The transactions are identical but arrive by different routes.
- Overlapping file ranges. Two statement uploads whose date ranges overlap by a day.
- Re-connecting an account. A reconnection that re-fetches history already imported.
- A processor payout and its underlying sales. The payout lands in the bank and the individual sales arrive from the sales channel. Both are real; only one is income. See Commerce.
- A transfer between your own accounts. It appears twice — once as money out, once as money in — and if both are categorised as income and expense rather than as a transfer, revenue and costs both inflate.
The module detects exact duplicates on ingest and flags near-duplicates for review. The two it cannot detect by itself are the last two, because both legs are genuinely different transactions. Categorise transfers as transfers, and treat processor payouts as settlement rather than income.
A feed is a copy. The closing balance on the statement is the fact. If the module's balance and the statement disagree, the feed is missing something or holding something twice — do not adjust the ledger to match the feed.
Posting rules
A posting rule matches on the description, the amount, the direction or the counterparty and applies a category deterministically. Rules are the mechanism that turns a monthly categorising chore into a weekly glance, and they reduce classification spend at the same time, because a transaction a rule claims is never sent to a model.
- Write a rule the second time you categorise the same thing, not the tenth.
- Rules run before the agent, so a rule always wins.
- A rule can post to a dimension as well as an account.
- Rules are visible and editable at
/accounting/posting-rules— they are not a black box.
What this does not do
Coverage depends on the provider. Where there is no feed, statement upload is the supported path.
A transaction nothing matches waits for a person. That is deliberate.
An account is held in one currency.
There is no cheque-scanning or lockbox integration.
Questions
How far back does a feed import?
Depends on the provider, typically 90 days to two years. Older history is a file import.
What if a transaction is categorised wrongly?
Change it. If it has already posted, the change is a journal entry and the audit trail shows both.
Can we exclude personal transactions?
Yes — exclude them in the staging area and they never post.
Related
Matching bank transactions to invoices, bills and journal entries in erp.io — the suggestion queue, confidence thresholds, and why you should never lower one to clear a backlog.
CommerceConnecting sales channels to erp.io Accounting: the clearing model, the Shopify connector, Amazon settlement files, and the tax traps that make a payout balance wrongly.