Uploading a bank statement is not reconciling it

This page is for the people who load bank files into LEAT, and for
anybody who wonders why a payment still says unknown the day after the
statement arrived.

Uploading a file settles nothing

When you upload a statement, LEAT stores it, records that it arrived, and
reads it. That is all.

Every line it reads becomes a claim from a file. A claim is not evidence.
It sits in a list until a reconciler looks at it and says which payment it
is about, and only that act moves anything.

This is deliberate. A file is the easiest thing in the world for somebody
to produce, and a system where uploading one marked eighty people as paid
would be a system where anybody who can send an email can mark eighty
people as paid.

What to do after you upload

1. Open the import and read the report. It tells you how many lines were accepted and how many were refused.
2. Deal with the refused ones. A file of eighty lines that produced seventy nine records has one payment missing from it, and nothing else will tell you which.
3. Go to the reconciliation screen and match the accepted lines to batches. This is the step that actually settles anything.

Why a line gets refused

The refusal always names the column and says what to do. The three
commonest are worth knowing in advance.

• The date could not be read. The file is not in the format we told LEAT to expect. Either the bank changed it, or the format was described wrongly when it was set up. Somebody compares the two before the next import.
• The outcome word is not one this feed declares. The bank has used a word nobody mapped. LEAT will not guess: reading an unfamiliar word as a success is how a returned credit gets reported as paid.
• Wrong account or wrong currency. The line is about a different account from the one this feed covers. Importing it here would put it on the wrong batch.

Refused rows are kept, with the reason and the row number. They never show
the value that failed, because a bad account number in an error report is
still an account number in an error report.

The same file twice is one import

Drop Monday's statement in again on Tuesday and nothing happens twice.
LEAT recognises the file by the exact bytes it contains, so a redelivery
does nothing and a corrected file is a new import that is read on its own.

A file is scanned before it is read

Every statement is checked for malware before anything opens it. Until
that check comes back clean, the file sits in LEAT unread. Nobody can
download it and the reader will not touch it.

Three things can happen.

• Clean. The file is read, and you get the report described above. This is the ordinary case and you will not notice the step.
• The scanner found something. The import is refused and the file is never read. We keep the bytes, because they are the evidence of what arrived, and somebody will ask you where the file came from. Check the machine you downloaded it on before you try again.
• The scanner could not answer. It is down, or it took too long. The file stays exactly where it is, unread, and the import shows as one nothing has looked at.

That third one surprises people, so it is worth being plain: a scan that
did not finish is not a scan that passed. LEAT would rather leave a
statement unread for an afternoon than open one nothing checked. Tell
whoever runs the servers, and load the file again once the scanner is
back. Nothing is lost by waiting and you do not need a new file.

What protects you besides the scan

The reader itself. It reads plain delimited text and nothing else: no
spreadsheets, no documents, no archives. It runs nothing, opens no network
connection, and evaluates no formula. When we export a report for you to
open in a spreadsheet, anything that looks like a formula is escaped so
your spreadsheet shows it instead of running it.

On a developer's own machine there may be no scanner at all. Where that is
so, every import says so on its own record rather than letting the absence
look like a tick. That configuration is refused everywhere else.

Nothing here reaches a bank

LEAT has no connection to any bank and holds no banking credential. A file
gets here because a person downloaded it from the bank's portal or because
it landed in a folder. There is no code in LEAT that could ask a bank for
anything or send it anything.