Turn statements into a register

Bank and POS statements go in; a categorised register comes out — everything sorted, refunds and reversals kept out of income, VAT separated, and a list of anything that needs a person to decide.

This is the Transaction Records & VAT Register package. You clone it once per business, tell it what that business does, and hand them a page they can upload to.

It prepares records. It does not file tax and does not advise on it. The figures are for the business's accountant to confirm. Nothing here says what is owed to anyone, and it should not.

Setting it up for a business

Templates → Transaction Records & VAT Register → Use template. A copy lands in your workspace.
Rename it for the business. The name is the heading they see on their page, so "Chizies Spices — Records" beats "Transaction Records (1)".
Open Settings and fill in the knowledge. This is the part that matters — see below.
Open the Statements tab and try a real statement before anyone else does.

The Statements tab only appears on projects that use this template, so you will not find it on your other work.

The knowledge is what makes it theirs

The agent can read a statement. It cannot know that a payment to MOBILEUNION is your client's supplier, or that airtime purchases are staff expenses rather than sales. Everything ambiguous is decided from what you write here.

Worth putting in:

What the business sells, in plain words.
Who the regular payers and suppliers are — the names as they appear in narrations, which are often nothing like the trading name.
Anything that looks like income and isn't — loan drawdowns, money moved in from the owner, contributions collected on someone else's behalf.
Anything that looks like an expense and isn't — stock bought for resale, float moved to a POS terminal.

A statement read without this still works. It just leaves more rows for a human, which is the honest outcome rather than a wrong one.

Using the page

On the Statements tab:

The file. CSV or Excel, as the bank or Moniepoint, OPay or PalmPay exports it. No need to tidy it first — statements put account details and summaries above the real headings, and that is expected.

About this business. Optional, and it goes to the agent alongside the knowledge. Use it for anything true of this statement in particular: "the transfers to ENO INYANG in July were a refunded deposit, not purchases."

VAT. A statement cannot tell you what a business charged its customers — a bank itemises VAT on its own fees and nothing more. So you say:

What you tell it	What you get
Nothing	The register says VAT was not supplied, and no position is worked out
My prices include VAT	VAT is taken out of trading income at 7.5%
VAT I charged this period	That figure is used instead

Use the second when the business knows its own number from its invoices — not every credit on a statement is a sale, so their figure is usually the better one. Give both and the register uses theirs and points out the difference, which is worth a look.

Then Build the register. It takes up to a minute: the agent reads a sample of the file, works out its shape, writes classification rules, runs them, reads what did not match, refines, and runs again.

Reading the register

148 transactions read, 141 classified, 7 not.

Money in               3,147,153.75
Money out              3,157,800.48
  trading income       2,007,100.00
  not income           1,140,053.75   (reversals, refunds)
VAT paid on charges           50.30

Trading income is the number that matters, and it is not the total of the credit column. On the statement above, ₦1,140,000 of what came in was a failed-transfer reversal and a refund — money returning, not money earned. Counting credits as income there would overstate turnover by more than half and have the business pay tax on ₦1.1m it never made.

"Not classified" is a feature. Those rows are left out of every total and listed so someone can look at them. A handful at the end is the correct outcome — they are the transactions whose narration genuinely does not say what they were.

If you see zero unclassified on a real statement, be suspicious rather than pleased: it usually means a rule got broad enough to swallow rows it did not understand, and the totals will look right and be wrong.

Check the categories for the impossible. A category called "Customer payment" with money going out of it means a rule is catching both sides of the account. Tell the business, or fix it in the knowledge and run again.

What it does not do

It does not see cash. Money that never touched a bank or a terminal is not in the file, and the register will not pretend otherwise.
It does not join accounts yet. One statement at a time. A business with several accounts needs each read separately for now.
It does not read PDFs yet. CSV and Excel only. Most banks offer both.
It does not say what is owed. Deliberately.

Your client's file

The statement is read into memory, used, and forgotten — nothing is stored. There is no copy on our servers to lose, and re-running means uploading again. For an accountant handling someone else's bank records, that is usually the first question, and it is a good answer.