The ledger does
the boring half.
Qwikr settles the obvious transactions with arithmetic, puts a model on the ambiguous ones, and leaves the judgement calls to you — with a full audit trail behind every decision.
Built for the work, not the demo
Reconciliation is mostly repetition with a few genuinely hard cases buried in it. This is aimed squarely at the repetition.
Deterministic matching first
Exact amount, date-window and reference matching runs before any model does. The obvious matches are settled by arithmetic, not by a guess, so the AI only sees what is genuinely ambiguous.
Categorisation that learns
Every correction you make becomes training signal for that client. Recurring suppliers stop being questions after the first time you answer them.
Bank rules you control
Write explicit rules on payee, amount, direction or reference. Rules always beat the model, so anything you care about behaves predictably.
Receipt and bill OCR
Extract supplier, date, net, VAT and gross from a photo or PDF, then match it to the bank line it belongs to and attach it to the transaction as evidence.
Duplicate and fraud checks
Documents are screened for duplicates, altered totals and mismatched supplier details before they reach the ledger.
Trial balance review
An AI pass over the trial balance flags the accounts that moved unusually, the ones that never move and the postings that look misfiled.
Automation rules and playbooks
Chain conditions and actions together — chase the client, post the journal, create the task, send the email — and run them on a schedule or a trigger.
Ask your ledger
A chat assistant with real context on the books. Ask why gross margin moved, which invoices are overdue, or what changed since last quarter.
Period-end checklist
Generate a close checklist from the state of the books rather than a static template, so the list reflects what this client actually needs.
Rules and arithmetic before anything clever
Most transactions are not hard. A £48.00 debit to a supplier you pay every month, on the date the invoice said, matching an open bill for £48.00, is a solved problem — and solving it with a language model is slower, more expensive and less reliable than solving it with a comparison.
So Qwikr runs the deterministic pass first: exact and tolerance-based amount matching, date windows, reference and payee matching, and your own bank rules. What survives that is the small pile of genuinely ambiguous lines, and that is what the model is asked about.
- Exact, tolerance and part-payment matching against open invoices and bills
- Bank rules on payee, reference, amount, direction and account
- Split a single bank line across several invoices, or several lines into one
- Statement-level reconciliation with a running difference you can actually close
Nothing posts behind your back
Automation in accounting fails in one specific way: something posts quietly, nobody notices, and the error is discovered at year end when it is expensive. The queue exists so that cannot happen.
Every AI-proposed action lands with its confidence, its reasoning and the evidence it used. You approve individually or in bulk, and you choose which action types are ever allowed to run unattended. Approvals, rejections and unattended runs all land in the same audit log.
- Confidence and reasoning shown against every suggestion
- Bulk approve the routine, open the ones that matter
- Per-action-type permissions for what may run unattended
- Full audit trail — who approved what, when, and on what evidence
Questions, answered
Not unless you tell it to. Suggestions land in a queue for approval, and you decide which categories of action are allowed to run unattended. Anything the model does post is written to the audit log with the reasoning attached, so it can be traced and reversed.
You recategorise it as you would anything else. That correction is fed back for that client, so the same supplier is not asked about twice. Because matching is deterministic first, the errors tend to sit in genuinely ambiguous transactions rather than in the routine ones.
No. Client data is not used to train third-party foundation models. The learning that happens is per-tenant pattern matching inside your own instance, and it stays there.
Yes. The AI features sit on top of a complete conventional bookkeeping system — bank rules, manual matching and journals all work without any model involved. Practices that would rather not use AI can disable it and lose nothing structural.
VAT treatment comes from the tax rate on the account and the scheme configured for the client, not from the model. The AI proposes a category; the VAT consequence of that category is calculated deterministically, and the VAT diagnostics run separately to flag returns that look wrong before you file.
See it run against your own bank feed
Start a free trial, or walk through the platform with us. No card required to look around.