TL;DR
- A processor statement is several documents in one: header, summary, sales and deposits, fees, chargebacks, reserves, and a tax total.
- Most finance teams can read half of it, and map even fewer lines back to the contract term that priced them.
- You cannot verify a charge you cannot read, so reading the statement section by section is the first step.
Short answer
A payment processor statement is not one document. It is several stitched together: an account header, a summary box, the sales and deposit detail, a fees section, a chargeback section, and often a reserve line and a tax total. Most finance teams can read maybe half of it, and can map even fewer of its lines back to the contract term that priced them. That gap matters, because you cannot verify a charge you cannot read. Reading the statement is the first step. A statement has a predictable set of sections, and each part comes from a different place. For the deep, line-by-line check of the fee invoice against your contract, see how to read a PSP invoice.
What a payment processor statement actually is
A processor statement is the monthly record of everything your payment provider did with your transactions and charged you for. It is not the same as two documents people confuse it with.
It is not a bank statement. A bank statement shows money moving in and out of your account. A processor statement shows the transactions your provider processed, the money it deposited to you, and the fees it took along the way. The deposit figures should reconcile to your bank, but the two documents answer different questions.
It is also broader than a fee invoice. A fee invoice, covered in how to read a PSP invoice, is the fee-line document, and reading it against the contract is its own task. The statement wraps that invoice inside the full record: sales, deposits, disputes, and reserves as well as fees. So a statement is the whole picture, and the fee invoice is one section of it.
The anatomy of a statement, section by section
Read a statement the way you would read any structured document: know what each section is for before you check the numbers in it. Most statements carry the same parts, in roughly this order.
The header and account information
The top of the statement identifies the account: your business name, the merchant identifier that your provider uses to track you, the statement period, and the pricing plan on file. This is the part everyone skims. Read it, because a wrong merchant identifier or a pricing plan that does not match what you signed means every number below it is being computed against the wrong terms.
The summary box
Below the header sits a summary: total sales volume, total transactions, total fees, and the net amount deposited. This box is the executive view, and it is where you sanity-check the shape of the month before you dig in. It also produces one number worth watching, the effective rate, which is total fees divided by total volume. The figures here are illustrative, meant to show the calculation rather than to state a real rate: fees of 30 thousand dollars on a million dollars of volume is a 3 percent effective rate. A jump in that rate from one month to the next is a reason to look closer, not proof of an error on its own.
The sales and deposit detail
This section reconciles what you processed against what you were paid. It lists sales, refunds, and adjustments, then shows the deposits made to your bank. The job here is to confirm that sales minus refunds minus fees equals what actually landed in your account. A deposit that does not tie out is the first sign that something in the fee or reserve sections is off.
The fees section
This is the fee invoice, embedded in the statement. It lists every charge your provider took: interchange, the card network's fees, your provider's markup, per-transaction fees, and the periodic charges. It is the most scrutinised section and the hardest to verify, because each line has to be checked against a different term in your contract. Each of those lines has its own source and its own check, and the fee invoice guide takes them one by one.
The chargebacks and adjustments section
When a cardholder disputes a transaction, the reversal and its fee appear here, not in the main fees section. Adjustments, such as a correction to an earlier deposit, also land here. Read this section against your own dispute records. A chargeback fee for a dispute you never received, or an adjustment with no explanation, is exactly the kind of item that hides in a part of the statement people do not read closely.
The reserve line
Some providers hold back a share of your funds against future risk, called a reserve. If you have one, the statement shows the amount withheld this period and, ideally, the release schedule. A reserve is your money held temporarily against future risk, rather than a fee, so it belongs on its own line in your thinking. Confirm the amount withheld and the release timing match your contract, because a reserve held longer or larger than the terms allow is a working-capital cost that a fee-only review misses entirely.
The tax reporting total
Many statements carry a year-to-date total for tax reporting, the figure your provider reports to the tax authority for your account. It does not affect your fees, but it should match your own records, because a mismatch here becomes a reconciliation problem at year end.
The fee lines, decoded
The fees section deserves its own map, because each line comes from a different source and is checked a different way. For the full treatment of what to challenge on each line, the PSP invoice guide takes them one at a time.
| Statement line | What it is | Where it comes from | How to check it |
|---|---|---|---|
| Interchange | The card network's baseline cost per transaction | Set by the card network schedules rather than your provider | Confirm the qualifying category matches the card type and channel of the actual transaction |
| Scheme and assessment fees | The card network's own charge for using its rails | A network-published rate you cannot negotiate | Confirm the rate matches the current published network schedule |
| Processor markup | Your provider's margin on top of interchange and assessments | Your contract's pricing schedule | Match it against the markup your contract discloses for your pricing model |
| Per-transaction fees | A fixed fee per transaction, separate from the percentage rate | Your contract's per-item pricing line | Multiply by the transaction count and compare to the billed total |
| Monthly minimum | A top-up charge when your fees fall below a floor | Your contract's minimum-volume clause | Check the floor amount and any waiver period against your contract date |
| Compliance and statement fees | Charges for compliance programs and document generation | Your contract's ancillary-fee schedule | Confirm you are not billed for a compliance status you already hold |
| Chargeback fees | A fee charged when a transaction is disputed | Your contract's dispute-fee clause | Confirm the fee applies only to disputes the contract does not waive |
| Reserves | Funds withheld against future risk | Your contract's reserve clause, if any | Confirm the amount and release schedule match the clause rather than provider discretion |
To read the markup line at all, you first need to know which pricing model your contract uses, which is its own diagnostic: see interchange plus, interchange++ or blended.
Mapping a line back to the contract
Reading the statement tells you what you were charged. It does not tell you whether the charge was right. That is the next step, and it is harder, because a statement and a contract are written in different languages. The statement speaks in totals for a month. The contract speaks in conditions: this rate applies to this card type on this channel above this volume. Verifying a line means resolving the contract condition that should have priced each transaction, then checking the charge against it.
That resolution is a real piece of work, covered in how a signed contract becomes a per-transaction check. When a line does not match, the shape of the mismatch usually falls into one of a few known discrepancy types: a rate that drifted, a fee charged twice, a charge applied in the wrong window.
What reading alone cannot tell you
A person reading a statement can catch a wrong effective rate, a deposit that does not tie out, or a chargeback fee for a dispute that never happened. What a person cannot do by eye is check every one of the thousands of individual transactions behind the summary against the contract term that should have priced each. The statement rolls all of them into monthly totals, and the errors that matter hide inside those totals, where a monthly total cannot see them.
That is the job Bluefyn is built for. Bluefyn reconstructs the contract into an expected charge for every transaction, compares it to what was actually charged, and flags the lines that do not match, so the totals on your statement can be traced back to the terms that should have produced them. It analyzes transaction and provider data. It never moves, holds, or custodies funds. Reading the statement is where verification starts. Checking every line behind it is where the money is.
Frequently asked questions
What is a payment processor statement?
It is the monthly record your payment provider gives you of everything it did with your transactions and charged you for. It bundles several parts into one document: an account header, a summary of volume and fees, the sales and deposit detail, the fees section, a chargebacks section, and often a reserve line and a year-to-date tax total. It is broader than a fee invoice, which is only the fees section, and different from a bank statement, which shows money moving through your account.
How do I read a payment processor statement?
Read it by section rather than top to bottom as one list. Start with the header and confirm your account identifier and pricing plan are correct. Check the summary box and the effective rate for the shape of the month. Reconcile the sales and deposit detail so that sales minus refunds minus fees matches what landed in your bank. Then work through the fees, chargebacks, and reserve sections, checking each against the document that governs it: your contract for fees and reserves, your own records for disputes.
What is the difference between a merchant statement and a PSP invoice?
A merchant statement is the whole monthly document: sales, deposits, fees, disputes, and reserves. A PSP invoice is the fee portion of it, the list of charges your provider took. The statement wraps the invoice inside the full record of the month. Reading the statement gives you the complete picture. Reading the invoice against your contract, line by line, is the deeper fee-verification task, covered in the PSP invoice guide.
Which fees on a merchant statement can I negotiate?
Interchange and the card network's scheme and assessment fees are set by the card networks and are the same for everyone, so they are not negotiable. What you can negotiate is your provider's markup on top of them, and sometimes the periodic charges such as monthly minimums and statement fees. Knowing which line is which is the point of reading the statement: it separates the costs that are fixed from the margin that is yours to question.
How do I know if a statement line matches my contract?
You resolve the contract term that should have priced the charge, then compare. For a rate line, confirm the rate matches your contract for that card type and channel. For a per-item fee, multiply the fee by the transaction count and check the total. For a reserve, confirm the amount and release timing against the reserve clause. Doing this once by hand for a sample teaches you the checks. Doing it for every transaction, every month, is a job for automated verification rather than a person.
