Categorizing bank and card transactions with AI

How the bot works

Nine steps. The validation, the rule engine, the duplicate checks and the audit trail are ordinary code and cost almost nothing to run; the model is only used to read a messy description and to explain itself.

1. It takes the lines in, however they arrive. A bank feed, a card export, a CAMT.053, MT940 or BAI2 file dropped on an SFTP, a CSV, or the PDF statement a client emails because the feed was never set up. All of them, normalized into one shape.

2. It validates the batch before coding anything. Opening and closing balances against the statement, no duplicate lines, no gap in the dates, nothing already in the books. A batch that does not tie out is reported, not coded — importing questionable data quietly is how a month gets lost.

3. It codes from a rule you can read. Your chart of accounts and your rules, written in words: this merchant to that account, this card to that class, this description pattern with this exception. Deterministic first, model second — the model only reads a description the rules do not cover.

4. It scores how sure it is, and stops under your floor. Under the floor nothing is coded. The line comes through uncoded with its best suggestion, the reason, and what would have made it certain. An empty field is a decision waiting to be made. A confident wrong answer is one that has already been made for you.

5. It recognizes what is not a category at all. A transfer between your own accounts, an owner draw, a loan or credit-card payment, an intercompany movement, a clearing-account line, a card batch that nets to nothing. Each one is named as what it is and handed over rather than coded to an expense.

6. It never invents a rule from one transaction. When it notices a pattern it proposes a rule, shows every line the rule would have affected going back as far as you like, and waits. You accept it, narrow it or throw it out. A rule that writes itself is a rule nobody chose.

7. It asks for the document when your rule needs one. Over your threshold, or in a category you have marked, the line stays open until the receipt or invoice is attached — and it asks the person who spent the money, by name, rather than leaving it for the close.

8. A person reviews, and a person posts. The coded lines, the uncoded ones, the handed-over ones and any proposed rules arrive as one worklist, grouped so a reviewer can accept the ordinary ones quickly and spend their attention on the few that need it. Posting is theirs.

9. It keeps the reason for every line. Which rule fired or which description the model read, the confidence, the evidence, who accepted it and what they changed. When somebody asks in March why a line was coded that way in October, there is an answer.

What you configure

It can be configured to run in any business. This is what that actually means — the list of things that are yours, not ours.

Your chart of accounts

The accounts, the classes, the locations, the tracking categories — as they actually are, including the ones that exist for one reason nobody has written down yet.

Your rules, in words

Merchant to account, pattern to account, card to class, amount bands, the exceptions. Readable, versioned, and yours to edit without asking us.

Your confidence floor

The score below which nothing is coded at all. Start it high. The dry run over a period you have already closed tells you where it actually belongs.

Your document thresholds

Where a receipt or invoice is required before a line can be coded, which categories always require one, and who gets asked for it.

Your not-a-category list

Transfers, owner draws, loan movements, intercompany, clearing and suspense accounts, payroll runs — what each one looks like in your data and who it goes to.

Your intake

Which accounts and cards, how the activity arrives, how often, and what happens when a feed goes quiet or a statement arrives as a PDF.

Your review and posting

Who reviews, who posts, what may be accepted in bulk, and whether anything at all is ever allowed to post without a person — which is off unless you turn it on.

Your period rules

Which periods are closed, what happens to a line dated inside one, and who is told.

Your systems

Which ledger holds the books, how the activity reaches us, and whether we read and write by API or by export.

Transparent, and configurable by you

The dark band below is what the system will not do. This is what you can see and change — and it is how we build everything, not something invented for this page.

You see what it did, and why

Every proposed line names the rule that fired or the description the model read, the confidence, and the evidence behind it. Every handed-over line names why it was handed over. You can audit a month by reading reasons rather than re-deriving the coding.

Versioned prompts you can tune yourself

The rules are words you can read and the prompts behind reading a description are yours to tune. A change is a reviewable diff, replayed against periods you have already closed so you can see exactly what it would have coded differently, and rolled back the same way.

A human in the loop wherever judgment actually matters

Validating, coding above your floor and proposing rules are automatic. Posting, accepting a rule, every transfer and draw, and anything touching tax or a closed period are a person's — that boundary is a property of the system, not a promise about how carefully we'll use it.

Every run logged, along with what it cost

One row per transaction and one per rule change: the rule and its version, the confidence, the evidence, the model and prompt version where a model was used, who accepted it and what they changed — plus token usage and cost for that run.

It can be configured to run in any business. The chart and the rules are yours: your accounts, your written rules, your confidence floor, your document thresholds, your closed periods. The bank-and-card wiring on this page is one configuration of it, not the limit of it.

Works with your tools

This runs on top of the ledger and the bank you already use. We're not replacing your accounting system or asking you to change banks.

• QuickBooks Online
• Xero
• NetSuite
• Sage
• A bank or card feed
• A CAMT.053, MT940 or BAI2 file
• Stripe
• Shopify
• A spreadsheet you control
• A PDF statement by email

Works well for

• Ecommerce sellers — Platform payouts arrive net of fees and refunds, and every deposit has to be broken back apart.
• Restaurants and food service — Card batches, delivery platforms and daily supplier runs make the feed long and repetitive.
• Trucking and logistics companies — Fuel, tolls, repairs and per-diem cards generate the same lines in every state, every week.
• Property management companies — Every line belongs to a property and a unit before it belongs to an account.
• Nonprofits — Spending has to carry a program and a funding source, not only an expense account.

How a rollout works

Nothing is posted on day one. The first milestone is a period you have already closed, coded again from scratch, line by line against what your team actually did.

1. 01Discovery

   The quote call, then a working session. We go through your chart of accounts, the rules as they exist today, your document thresholds, what counts as a transfer or a draw in your data, your closed-period rule, and who posts. You get the rule set written down, the exception classes and a written scope.

2. 02Dry run

   The bot codes a period you have already closed, from the activity you had at the time. Nothing is posted. We compare its coding against yours line by line, and every disagreement is either a rule we have not captured or a judgment call worth naming. This is where your own numbers come from, and where the floor gets set.

3. 03Assisted mode

   Live on one entity or one account first. The bot validates, codes above the floor and hands over the rest; your bookkeeper reviews and posts. Coding stops being typing and becomes reviewing. The control doesn't change.

4. 04Optional limited automation

   Optional, and narrower than it sounds. A short list of categories you name, under a confidence floor and an amount ceiling, with every hard stop in force, a sampled share still reviewed, and the kill switch. Plenty of teams stop at step 03, and that's a good place to stop.

What we don't claim

• No numbers we haven't earned. No accuracy figure, no share of lines coded without a person, no close-time claim. We haven't coded your books. An accuracy figure measured on somebody else's transactions tells you nothing about yours; the number that matters comes out of the dry run over a period you have already closed, and it will be yours.
• No customer claims on this page. No names, no case studies, no logos.
• It is not your accountant. It proposes a code with its reasoning. What your books say about tax, what is deductible, how a mixed-use asset is treated and which adjusting entries a year-end needs are your accountant's work, and the design deliberately routes those to them instead of answering.
• It will not be right about an ambiguous line. The honest cases genuinely divide bookkeepers — an owner's car payment out of the business account is a real argument with more than one defensible answer. The bot's job there is to recognize that it is one of those, name it, and hand it over.
• Fully autonomous coding isn't on offer. There is a floor under which nothing is coded, there are categories that can never be automated, posting stays with a person, and nothing is ever learned from one transaction. That's deliberate, and it's why the boundary is written down.

Questions people ask

Can AI categorize our bank and card transactions?

Yes - and what matters is where it refuses to. An agent can take the activity however it arrives, validate the batch against the statement before coding anything, and propose an account from your own chart using rules written in words you can read, with the model only reading the descriptions your rules do not already cover. Below the confidence floor you set it codes nothing. Transfers, owner draws, loan movements and intercompany lines are named and handed over rather than coded. A person posts.

How is this different from the bank-feed suggestions we already get?

Three things, and each one is a refusal rather than a feature. It does not answer confidently when it is unsure - under your floor the field stays empty with the reason attached. It does not teach itself a rule from one transaction - a pattern becomes a proposal showing every line it would have affected, and you accept or narrow it. And it treats transfers, draws, loan movements and clearing lines as not-a-category rather than finding them an expense account.

Does it post to QuickBooks or Xero by itself?

No, not by default and not as the normal way to run it. It proposes, grouped so a reviewer can accept the ordinary lines quickly and spend their attention on the few that need it, and a bookkeeper or accountant posts under their own login. If you later want a narrow slice posting unattended, it is a short list of categories you name, under a confidence floor and an amount ceiling, with every hard stop still in force and a sampled share reviewed anyway.

What happens when it is not sure?

Nothing gets coded. The line comes through uncoded with its best suggestion, the reason for it, and what would have made it certain - a receipt, a known merchant, a rule you have not written yet. That is the opposite of the usual failure, where a plausible category arrives with high confidence and somebody finds it three months later during a clean-up.

What about transfers, owner draws and intercompany movements?

They are handed over by design, because they are not categorization problems. Money moving between your own accounts, a withdrawal and redeposit that nets to nothing, a loan or credit-card payment, an intercompany entry, a clearing or suspense line: each is identified as what it is and routed to a person, with the matching side of the movement attached where it can find it. Coding those to an expense account is how books get wrong quietly.

Does it decide the tax treatment?

No, and this is the firmest line on the page. Whether something is deductible, how a mixed personal and business cost is split, whether a payment is a draw or a wage, whether a cost is capitalized: all of it goes to the person who owns your books. Those cases divide experienced bookkeepers, they often depend on where you are and what kind of entity you are, and they usually end with an adjusting entry from a tax preparer. The bot's job is to spot one and route it.

Can it create bank rules for us?

It can propose them, and that is deliberately where it stops. A proposal comes with every historical line the rule would have hit, so you can see the damage before you accept it, and you can narrow it or reject it. Rules that quietly create themselves are the thing that makes people turn automated coding off, and once accepted a rule is a readable, versioned line you can edit without asking us.

What if our transactions only arrive as a PDF statement?

That works. A feed is easier, but a PDF statement, a CSV export or a scheduled CAMT.053, MT940 or BAI2 file on an SFTP are all normal inputs, and all of them get the same validation first: balances tied to the statement, no duplicates, no missing days, nothing already in the books. A batch that does not tie out is reported rather than imported, which is the one thing you want from a statement nobody has checked.

Is there a record of why each line was coded that way?

Yes, per line. Which rule fired or which description the model read, its version, the confidence, the evidence, who accepted it and exactly what they changed - and the same for every rule change, with the lines it affected. When somebody asks in March why something was coded that way in October, you can answer without reconstructing it.