Reconciliation is where a bookkeeping file earns its credibility or quietly loses it. Most software treats it as a clearing exercise: match everything it can, as fast as it can, and count whatever cleared as finished. AIONA treats it as an evidence exercise. A bank line is reconciled when a person has seen the proposed match, understood why it was proposed, and accepted it. Everything else is still open work, and the software says so.
Getting bank data in
Statement import is the supported route today. AIONA accepts CSV, OFX and QIF exports and reads PDF statements, which between them cover what UK banks routinely produce. Open Banking feeds are rolling out, and when a feed goes live for a client the statement route stays available alongside it, because a statement is a natural fixed point to close a period against.
We say this plainly because live feeds are often presented as universal when they are not. What matters to the file is not how the data arrived but whether every line was dealt with honestly. That is where AIONA does its work.
A written reason on every proposed match
When AIONA proposes a match between a bank line and a ledger item, the reason is written on the line itself: the reference contains the invoice number, the amount agrees and the date falls inside the expected window, or this counterparty has paid this way before. Not a bare percentage, and not a green tick you are asked to take on faith, but a sentence you can verify in the time it takes to read it.
The same principle runs through the whole platform: confidence has to mean something checkable, and low confidence has consequences. A match AIONA is unsure of is never dressed up as a certain one. You can read how we hold ourselves to that on the accuracy page.
Flags instead of silent clearing
Some lines look almost right, and almost right is where the damage hides. The amount matches an open invoice but the counterparty name does not. Money moves in the wrong direction for what it is matched against: a receipt where a payment should be, or a refund with no purchase behind it. A line that looks like a duplicate of one already cleared.
AIONA does not clear these quietly and move on. The line enters a flag state with the anomaly named: counterparty mismatch, direction anomaly, possible duplicate. You see exactly what troubled the software before you decide anything. Silent clearing is how errors calcify into a file and resurface months later in a VAT return or a year-end review; we set out why we refuse to do it in review-first versus silent automation.
Accept or reject: the decision stays human
Nothing clears until you accept it. Accept, and the match is made and recorded. Reject, and the proposal dissolves: the bank line stays open, the ledger item stays open, and no residue of the wrong guess is left in the books. Every acceptance and rejection lands in a tamper-evident audit trail, so when anyone asks who reconciled a line and on what basis, the file answers for itself.
Rules learned from your confirmed matches
When you accept the same kind of match repeatedly, the same counterparty to the same account or the same reference pattern, AIONA learns it and starts proposing it with that history attached. Two boundaries hold. Learned rules are scoped to your practice: your corrections teach your AIONA and nobody else's. And a learned rule only ever proposes; it never acquires the right to clear a line without you.
Lines with no invoice behind them
Bank charges, small purchases, direct debits with no bill in the system: not every line has a document waiting for it. For those, categorise the line straight to a ledger account. AIONA creates the journal and the match together in one action, so the ledger entry and the reconciliation can never drift apart, and the journal links back to the statement line as its source, the same way every journal in AIONA links to the document it came from.
The full UK chart of accounts is seeded on day one with control accounts locked, so an un-invoiced line cannot be pushed somewhere that corrupts a control balance. And if a line really needs a document that has not arrived, the client portal lets you ask for it: the client's upload lands against the right transaction, not in a shared inbox.
Sessions, and a percentage you can stand behind
Reconciliation runs in sessions: open one against a statement or a date range, work the lines, and the session records what was decided. The reconciled percentage means one thing only, the share of lines a person has actually accepted. It never includes lines the software matched but nobody confirmed, because that state does not exist in AIONA. When a session reads 100 per cent, that is a statement about human decisions, not machine guesses, which is why the VAT figures built from those journals are ones you can defend, and why the file holds up to the questions in what audit quality looks like in a bookkeeping file.
The boundary: AIONA holds what it cannot vouch for
Some lines will not resolve on the day. AIONA holds them. It does not force a match to flatter the percentage, and it does not sweep the residue into a suspense account and call the period done. An unresolved line stays visibly unresolved until a person deals with it. Underneath, nothing posts without human sign-off, the ledger is immutable and corrections are made by reversal, so the reconciliation you signed off is the reconciliation that persists.
Reconciliation is included in the per-client price of £24 per month, with unlimited users and AI included, and your own company plus your first client free. Your data exports to CSV or Excel at any time with no exit fee. See pricing, or talk to us and reconcile a real statement on a test book.