In the last few weeks I have come to realise the importance of the SEPA Batch Booking tag, <BtchBookg>. The tag is one I was familiar with, but didn’t realise the significance of. During a SEPA payments go live we started seeing a debit for every single payment in the bank statement. Oh nuts! The requirement was to receive a single consolidated debit within the bank statement to automatically match, within our ERP, and in turn close off the open payable. So what controls this? <BtchBookg> !
What is <BtchBookg> ?
<BtchBookg> or Batch Booking is a tag within the SEPA XML file which defines how the debit should be handled. The debit can be a single consolidated debit (sum of all of the payments) or multiple debits (for each payment within the file).
What Values are Permitted within the Batch Booking Tag?
It depends, so check with your bank. But the standard values seem to be:
- TRUE – Giving as consolidated/single bulk debit
- FALSE – Indicating individual and multiple debits
Some banks require the value to be ‘1’ (Consolidated debit) or ‘0’ (multiple debits). Check your banks requirement…
Do I need to worry about <BtchBooking>?
Errrm – maybe! Most banks default this value to give you a consolidated debit, but other banks may default it to multiple individual debits. So check with your bank if/how they are defaulting this tag. If the bank default value fits your requirements, great. You don’t need to worry about it.
But if the banks default value does not meet your requirements, add the tag to your XML format.
Why do I need to worry about the Batch Booking?
1. It depends on your back office process. If your ERP process looks at the bulk debit on the bank statement, and automatically closes the payable within your ERP based on a consolidated single debit. You need to make sure you’re receiving a single and consolidated debit amount from the bank. If you’re not, then you have to manually match each bank statement debit to the open ERP single debit. Equally if you require multiple and individual debits, and receive a single/consolidated debit in the bank statement then you have a problem.
This will cause your treasury team a headache, increase the amount of manual processing and in turn reduce their overall efficiency.
2. The bigger problem and concern is for your Payroll process. Imagine your payroll process makes use of a shared bank account, and the legacy process resulted in a single consolidated bank statement debit. Your employee confidentiality remains in tact, and there are no concerns. Now, with the shift to SEPA imagine the debits are reported as individual line items. Since it is a shared account various team will now have access to see the details of each salary payment under SEPA. Oh crap! You need to make sure this does not happen. This is why the Batch Booking tag is crucial, or at least knowing from your bank how they will handle the debit based on your sample/test files.
How does the BatchBooking tag work?
The consolidated amount or individual payment amounts are indicated for every transaction (tag <CdtTrfTxInf>, Credit Transfer Transaction Information) within the batch (tag <PmtInf>, Payment Information).
So if I have 5 CdtTrfTxInf transactions, each for 1 EURO, within a single PmtInf, the debit would be handled as follows:
- <BtchBooking>TRUE<BtchBooking> —- would report a single debit value of 5 EURO, with a batch reference
- <BtchBooking>FALSE<BtchBooking> —- would report 5 individual debits, each for 1 EURO, with reference details of each transaction
Don’t be caught out, especially with payroll. It could compromise the confidentiality of the salary payments and land you in big trouble. On the other hand the Batch Booking can significantly impact and hinder your back office Treasury team and divert them from value added tasks.
Has this tag been a consideration in your SEPA project?