← All guides

CtrlSum and NbOfTxs: how control totals in pain.001 are calculated

How the two summary numbers in every pain.001 file are computed, why they live at two levels, how rounding breaks them, and how to fix a mismatch for good.

Every pain.001 file grades its own homework. Near the top of the file, the group header states how many payments the file contains and what they add up to. Each payment block repeats the same two numbers for its own payments. These are the control totals: NbOfTxs, the number of transactions, and CtrlSum, the control sum. The bank reads your numbers, adds up the actual payments, and compares. If the two answers differ by even one transaction or one cent, the file is rejected. Control totals exist because payment files are too important to trust blindly: they let any system in the chain prove that what arrived is what was sent, complete and untampered. This guide explains exactly how each number is calculated, where teams get them wrong, and how to make the mismatch class of rejection disappear from your life.

The two numbers, defined precisely

NbOfTxs is a count. At group header level it is the total number of individual transactions in the whole file — the number of CdtTrfTxInf elements, summed across all payment blocks. Inside a payment information block (PmtInf), NbOfTxs is the count of transactions in that block only. CtrlSum is money. At group header level it is the sum of every instructed amount in the file. At block level it is the sum of the instructed amounts in that block. One subtlety matters here: the sum uses the InstdAmt of each transaction — the amount as instructed, in its own currency — added as a plain decimal total. If a file mixed currencies, the header sum would still be the plain arithmetic total of the numbers, which is one more reason SEPA files stick to euro only: the control sum only makes real-world sense when every amount shares a currency.

Worked example. A file has two payment blocks. The first block pays three suppliers: 100.00, 250.50 and 1,000.00 — block NbOfTxs is 3, block CtrlSum is 1,350.50. The second block pays two salaries: 2,300.00 and 2,300.00 — block NbOfTxs is 2, block CtrlSum is 4,600.00. The group header must then say NbOfTxs 5 and CtrlSum 5,950.50. If the header says 5,950.00, or 6 transactions, the file fails, even though all five payments are individually perfect. Notice the built-in cross-check: the header totals must equal both the sum of the block totals and the sum of the transactions directly. That redundancy is the design. Any single error in any of the three places — a transaction, a block total, the header total — creates a detectable contradiction.

Why mismatches happen: edits after export

The most common cause is a human helping. The export is correct when the ERP writes it. Then someone notices a wrong amount, opens the file, fixes the payment — and does not know the totals exist, or knows and updates one level but not the other. The file now contradicts itself. A close cousin: a payment is removed in the bank portal or in a spreadsheet on the way, and the count and sum quietly go stale. The rule that prevents the entire class is simple to state and hard to enforce socially: an exported payment file is a sealed document. If a payment must change, change it in the source system and export again. Any tool that touches the file after export must recompute both total levels as part of the same operation. If your process cannot guarantee that, validate after the last touch — our pre-flight routine puts the totals check at exactly that point.

Why mismatches happen: rounding and floating point

The second cause is arithmetic done in the wrong kind of numbers. Computers offer two ways to store decimals: floating point, which is fast and approximate, and exact decimal arithmetic, which is slower and right. Money belongs in the second kind. In floating point, 0.1 has no exact representation, and adding thousands of amounts can drift the total by a cent in either direction. The transactions in the file are written with two decimals and are exactly what they say; the header, computed in floating point and then rounded for display, can land a cent away from the true sum. The file then fails its own arithmetic while every visible number looks correct — the most confusing rejection of all, because the human adds it up, gets the true total, and concludes the bank is wrong. The bank is not wrong; the header is. Export code must sum amounts as decimals (or as integer cents) end to end. Our validator recomputes totals with exact decimal arithmetic for the same reason, and it is why we can state a one-cent difference with confidence.

Edge cases: fees, equivalent amounts and multiple blocks

Three details trip up careful teams. First, only the instructed amount counts. If a transaction also carries an equivalent amount in another currency (EqvtAmt), that figure is information for the bank, not part of the sum; including it double-counts. Second, charges are not subtracted: a payment of 100.00 with charges handled separately still contributes 100.00 to CtrlSum. Third, blocks matter: a file with a correct header and one wrong block total still fails, because the bank checks consistency at both levels, and the block check is often the one that localises an error — if block B’s total is wrong and the header equals the sum of the blocks, the error sits inside block B’s transactions or its total, which halves your search space. Read the two levels as a diagnostic tool, not just a hurdle. When totals disagree, compare header against sum-of-blocks first, then blocks against their transactions, and you will always know which layer introduced the error.

Optional in the schema, mandatory in real life

A technicality worth knowing: in the raw ISO schema, CtrlSum is optional, and NbOfTxs at block level has its own optionality. Teams occasionally discover this and ask whether leaving the totals out avoids the whole problem. It does not. Scheme rulebooks and bank guidelines require the values to be present and correct, because the totals are part of how banks protect the integrity of the file in transit. An absent CtrlSum is treated as a defect, not as neutrality — one of many examples of the gap between what the schema tolerates and what banks accept, which we explore in the guide to bank implementation guidelines. Include the totals, compute them exactly, and check them like the bank does.

The happy ending for this particular error class: it is one of the few that software can repair mechanically. If the transactions are right and only the stated totals are wrong, the corrected file is fully determined — recompute and rewrite the four numbers. Our Pro plan offers exactly that: when every error in a file is a count or total mismatch, you can download a corrected file with the totals recomputed, instead of sending the file back through a full ERP re-export cycle. See pricing for which plans include corrected downloads and exports. Use the convenience wisely, though: a corrected file fixes the symptom, and the export bug that caused it will happily produce the same mismatch next month. Fix the file when you are in a hurry; fix the exporter when you are not.

How to verify the totals by hand in five minutes

You do not need software to audit a small file, and knowing the manual method makes the software’s report easier to trust. Open the file and find the group header: note its NbOfTxs and CtrlSum. Then find each payment block and note its two numbers. Add the block counts: they must equal the header count. Add the block sums: they must equal the header sum. Now pick one block and add its transaction amounts with a calculator, entering each amount exactly as written — two decimals, no rounding shortcuts. If all three comparisons agree, the file’s arithmetic is sound. If one disagrees, the pattern table above tells you which layer to suspect. For files with more than a few dozen payments, sample instead of exhaust: verify the block totals add to the header, then fully recompute one block. A mismatch anywhere is a stop signal for the whole file, because the bank will find it with certainty; totals are the one check no bank samples or approximates.

While you are in the header, two neighbouring habits are worth forming. Check that the number of payment blocks matches what you intended to send — a file that silently lost a whole block passes every totals check, because the totals describe the file as it is, not the file as it should be. Control totals prove internal consistency, not completeness against your intentions; only your own run record can prove that. And check the creation timestamp is fresh. A file regenerated after a fix should carry a new creation time and a new message identifier; a file whose header still shows last week’s timestamp is the old export wearing a new name, and its totals — however consistent — describe payments you may already have sent. Totals, identifiers and timestamps are the header’s three stories about the file. Read all three before you trust any of them.

A closing thought on trust: control totals are often described as the bank checking up on you, but the direction of protection runs both ways. The totals in your file are also your proof of what you sent. If a dispute arises — a bank claims a file arrived with a different amount, a payment goes missing in a chain of systems — the header you generated, kept with the run record, is the evidence of the file’s intended content, and a mismatch between the file in transit and the totals it carries proves the file changed after it left you. Keep the exported file itself, or at least its header values and hash, with the payment documentation for the same retention period as the payments. Teams think of CtrlSum as a hurdle the bank sets. It is better understood as a seal both sides can verify — cheap to apply, embarrassing to break, and quietly valuable on the one day in a thousand when something genuinely goes wrong between systems.

Make totals boring. If your export computes them last, in exact decimal arithmetic, from the final transactions, and your process forbids hand edits after export, this entire category of rejection — historically the most common one — simply stops occurring. That is the quiet promise of control totals done right: not that they catch errors at the bank, but that they catch them in your own pipeline, where an error is a five-minute fix instead of a missed payday. When you validate a file with our tool, the totals check is one of the first things that runs, and the report shows the stated and computed values side by side, so a mismatch explains itself.