SEPA CtrlSum mismatch: reconcile each payment block
Fix pain.001 CtrlSum mismatches with exact decimal totals per payment block and group. Understand the difference between XSD and local business checks.
Why a valid decimal can still be wrong
A payment batch can be well-formed XML and contain a decimal that its schema accepts, while still declaring the wrong total. CtrlSum represents a consistency check over transactions. If an ERP export calculates it before removing a rejected supplier row, the final file can carry an outdated amount. The remedy belongs in the exporter: sum the transactions that actually remain in the block and regenerate the declaration.
The local rule SEPA-SUM uses integer cents, so 0.10 plus 0.20 is compared exactly with 0.30. Floating-point rounding must not turn a correct batch into a spurious discrepancy. This check expects EUR instructed amounts with at most two decimal places; other amount representations fall outside this SEPA-lite scope.
Start with the smallest failing block
In the fictional example there is one transaction for EUR 25.00. A PmtInf/CtrlSum of 25.01 fails, with a location such as /p:Document[1]/p:CstmrCdtTrfInitn[1]/p:PmtInf[1]/p:CtrlSum[1]. The report also gives a line number. The p prefix denotes the selected pain.001 namespace; it does not need to match the prefix used in your file.
First compare that payment block with its own CdtTrfTxInf children. Then check GrpHdr against all payment blocks together. A correct group total can hide two incorrect block totals that cancel each other. Similarly, NbOfTxs counts transactions, rather than payment information blocks. Missing optional block totals are not invented by this tool; a bank may require them in its separate profile.
Correct the source and rerun both layers
Keep the intended transaction amounts intact while investigating. Do not change a supplier payment merely to make the declared sum agree. Check whether a row was duplicated, omitted, split into another currency, or excluded after totals were generated. Export a fresh file and run the local business checks again. Retain the report with the reference date and rule version for your own records.
Next supply the authorised ISO .09 XSD if you need schema validation. The lite demo deliberately reports XSD not executed without it. Even after a supplied schema passes, a complete EPC or bank rule set has not been established. Bank acceptance, available balance and submission cutoff require their own checks outside this validator.
Before and after
Before: business check fails
<CtrlSum>25.01</CtrlSum>After: this field passes
<CtrlSum>25.00</CtrlSum>These fragments belong to the complete fictional .09 file. The field correction alone is not proof of complete file validity. Download the broken example · Download the corrected example.
Primary references for control totals
The ISO repository catalogue provides the message definitions; use its archive to select the .09 artifact your bank requires. The EPC customer-to-PSP guidance supplies the implementation context. These sources do not turn this independent total-comparison rule into a complete EPC validator.
The application compares each present declaration with its own transaction scope, rather than substituting a bank-specific requirement. Review the BYO scope and notices before loading a schema. ISO remains the official source of current repository information.
Run the payment check
SEPA pain.001 validator · Related SEPA repair guide · Pro / Team for recurring batches