Map it once. Every client on that bank is done.
Every tool in this category eventually meets a statement it cannot read. What happens next is the difference. Most of them tell you to contact support and wait. Greenote lets you mark the columns yourself, on the real document, and then remembers that layout for every future statement from that bank.
7-day free trial, no card required. Works on PDF, Excel and CSV statements.
How it works, in three steps
1. Mark the columns on the real statement
Not on a preview or an approximation. For a PDF you drag cut lines down the actual page and label the gap between each pair. For a spreadsheet you mark the columns on the grid. You are looking at the document while you do it, so there is nothing to guess at.
2. Say what each column is
Date, narration, debit, credit, balance, or a single amount column where the bank prints one instead of two. Anything you do not need is marked "Not used", which keeps serial numbers, branch codes and value dates out of the data.
3. Tick "remember this layout"
Greenote stores the layout against that bank and applies it to every future statement in the same format, for every client. This is the step that turns a one-off fix into something you never repeat.
A layout is per bank, not per statement
This is the part that changes the arithmetic. The layout is stored against the bank, not against the file, so it applies to every client you have at that bank and to every statement they send you afterwards.
A firm with forty clients at the same co-operative bank spends two minutes once, in the first month, and never sees that problem again. The cost does not scale with your client base. That is the opposite of how a support ticket works.
The one case where a layout cannot be saved
If you map a statement under Others, the layout will read that file but will not be remembered. That is deliberate rather than a limitation we would rather you did not notice.
“Others” is not one bank. It is an address shared by every unlisted bank in your firm, so two of them that happen to print their columns alike would overwrite each other silently, and you would not find out until a statement read wrongly months later.
The way round it takes a few seconds. Type the bank's name in the picker and choose Add <name> as a bank. Now it has its own name, its own layout, and the layout can be remembered against it. Your firm ends up with a bank list that matches the banks your clients actually use.
What this is really for
25 banks have a reader written for their specific statement structure, so most files never reach this screen at all. Column mapping exists for the cases that are genuinely hard to cover any other way:
Co-operative, regional and small private banks, where the long tail is too long for any vendor to have written a reader for every one.
A bank that quietly changes its statement layout, which happens more often than anyone admits and would otherwise mean waiting for a software update.
A statement exported in an unusual way, or a spreadsheet a client has already edited before sending it.
Any format where the automatic reading looks wrong. Re-map, re-read, and check the figures against the statement rather than accepting them.
One thing it deliberately does not fix: a scanned statement or a photograph of a printout. There are no columns to mark, only a picture of them. Why a scan is the expensive file.
You see the reading before anything reaches Tally
Mapping changes how the file is read, not what gets written. Every transaction is shown to you first, and if a reading does not add up Greenote says so rather than importing it quietly. If something did reach Tally that should not have, an import can be reversed by deleting exactly what Greenote wrote and nothing else.
All of it happens on your own PC. The statement is not uploaded to Greenote or to any third party while you map it.
Column mapping: common questions
- What happens if Greenote cannot read my bank statement?
- You mark the columns yourself, on the real statement, and it reads. For a PDF you drag cut lines down the page and label the gap between them; for a spreadsheet you mark the columns on a grid. Then Greenote reads the file with your markings and hands it back to Import as normal.
- Do I have to do that for every statement from the same bank?
- No. That is the point of it. Tick "also remember this layout" and Greenote applies it to every future statement in that format, for every client on that bank. A firm with forty clients at the same bank does the work once.
- Which columns can I mark?
- Date, narration, debit, credit, balance, and a single amount column where the bank prints one instead of two. Any column you do not need can be marked "Not used", which matters because statements carry serial numbers, branch codes and value dates that would otherwise be read as data.
- My bank is not in the list at all. Can I still save a layout?
- Yes, but add the bank first. Search for it in the bank picker and choose "Add <name> as a bank", then map the statement and the layout can be remembered against that name. A layout cannot be saved under "Others", because that name is shared by every unlisted bank and two of them printing their columns alike would overwrite each other silently.
- What if I map it wrong?
- Re-map and re-read. The mapping is not a one-way decision: if the figures look wrong you go back, mark the columns again, and the statement is re-read from the file. Nothing is posted to Tally until you approve it.
- Does this work for co-operative and regional banks?
- That is mostly what it is for. The large banks have readers written for their specific structure. Column mapping is what covers the long tail of co-operative, regional and small private banks, and any bank that changes its layout without warning.