Settlement File

A settlement file is the report a provider sends with each payment run, setting out what is in it. It lists the sales that went in, the refunds and chargebacks taken off, the fees charged, and the one figure that will show on the bank statement. Without it a merchant sees only a deposit: one number, and no way to work out which orders it covers. With the file, each part of that deposit can be traced back to a sale. Any gap can then be named rather than guessed at.

The file is what makes matching possible at all. Finance teams read it against the order book to prove that the money taken and the money banked agree, and to find the lines that do not. Formats differ by provider, though a growing share now follow ISO 20022. That standard sets a common message shape, and it carries more set-out data than the fixed-width files it is taking over from. Scheme rules shape the content too, since the Visa Core Rules set out what each party in the chain is expected to pass on.

What Is Actually Inside One

A typical file has a header, a body and a trailer. The header names the acquiring processor, the merchant, the date and the run. The body is one row per event: sales, refunds, a chargeback and its reversal, and fee lines, each with a date, an amount and a reference. The trailer holds the totals and a count, so the reader can check that nothing was lost on the way. The figure that matters most is the net amount, since that is the one the bank will show.

Formats Differ More Than You Would Like

There is no one layout. Some firms send fixed-width text, some send CSV, some send XML built on a scheme standard, and some skip the file and offer the same data through an API that a finance system can call on a timer. Column names differ, date formats differ, and the sign on a refund differs: a minus in one file is a column of its own in the next. A firm taking money through three providers is parsing three shapes, and each of them can change with little notice.

Matching It To The Bank Line

One check counts. The trailer total in the file should equal the credit on the bank statement, to the penny. If it does, the file explains the deposit, and any row can be pulled up to settle an argument about a single order. If it does not, something between the file and the bank has moved: a second batch, a fee debited apart from the run, or a payout split over two credits. The general ledger is where that gap turns up in the end. Finding it on the day is far cheaper than finding it at year end.

Reading The Fee Lines

Fees are where a merchant learns what it is really paying. A file that shows interchange fees apart from the card scheme fee and the provider's own margin lets a firm see which card types cost what. A file that shows one blended rate says almost nothing. Where a provider offers both, the broken-out version is the one to ask for. It is what any serious look at the merchant discount rate depends on.

One File Per Provider

Running three acquirers means three files, on three schedules, in three shapes. The easy path is to check each one on its own and stop there. That misses the cases that cross providers, such as an order taken on one and refunded on another.

How Long To Keep Them

Files land on a set schedule, by SFTP, by API or in a portal. They are often there for a short window only, so a firm that does not pull them in time can lose the record. Disputes can arrive months after a sale, and tax records are kept for years. Keeping the raw file next to the parsed output is prudent for both. The raw file is the evidence; a row in a database after three steps is an argument.

The Traps That Catch People

Time zones head the list, since a file stamped in one zone and read against a bank in another will slide by a day. Duplicate references come next, because some providers reuse an ID across runs. Rounding is the quiet one: a fee shown to two places in a report may well be carried to four or five behind the scenes, so a month of small rounding gaps adds up to a figure somebody has to explain. And the sign on a refund catches nearly everyone once.

Making The File Work For You

Automate the parse, and store the raw file next to the parsed copy. Match every run, not every month, since a break found the same day is usually still easy to explain. Key each row on the merchant's own order reference, so the record survives a change of provider. Ask for fees broken out, and check the trailer totals rather than trusting them. Keep the funding instructions on file current, because a file that ties out is no help if the money went to an old account. Raise it early when a file is late, since a missing file is often the first sign of a settlement problem upstream. Where a firm pulls files from more than one source, this walkthrough of automated reconciliation across providers covers the matching logic. The payment orchestration product is designed to help pull those sources together.

‍