When processing PDF invoices, the IDR not only recognises standard payment details (IBAN and payment reference), but also specific payment situations that affect the payment code in the e-invoice.

When an invoice contains a direct debit notice (for example "This amount will be debited automatically"), this affects the payment code in the UBL invoice. The payment code determines how the receiving system handles the payment:

• For bank transfer: the standard payment code is used
• For direct debit: the payment code indicates automatic debit

It is important that your ERP system interprets the correct payment code, so that invoices with direct debit are not presented for manual payment while the amount has already been debited.

The Professional version of the IDR recognises G-account IBAN numbers on PDF invoices. A G-account is identifiable by the characteristic "099" sequence in the IBAN. The IDR records the G-account IBAN as a separate field in the e-invoice, separate from the supplier's regular IBAN.

A G-account (blocked account) is a bank account onto which the hirer or contractor deposits the estimated amount of payroll taxes and VAT. The balance can only be used to pay these taxes to the Dutch Tax Authority. The remainder of the invoice amount goes to the supplier's regular bank account.

The G-account is an instrument to reduce the risk of liability in:

• Chain liability (Wka): in subcontracting, the contractor may be held liable for payroll taxes and VAT that the subcontractor must remit.
• Hirer's liability: when hiring staff, the hirer may be held liable.

By depositing the relevant portion of the invoice amount into the G-account, the Tax Authority cannot hold the hirer or contractor liable for that amount (provided all conditions are met). A G-account can be opened by employers or subcontractors who seconded, lend, detach staff or take on work as a subcontractor. Sole traders without employees cannot open a G-account, as they are not withholding agents for payroll taxes.

G-account processing must be supported in the connection with your financial package. The software must be able to correctly process two partial payments: one to the G-account (for payroll taxes and/or VAT) and one to the supplier's regular bank account. If the package does not support this, eConnect can supply the data but the payment cannot be split correctly.

The G-account was originally developed for the construction sector (and is part of the DICO standard), but is more widely used in secondment, detachment and subcontracting across all sectors.

The IDR recognises the invoice number and, where present, the payment reference on a PDF invoice. Both values are always recognised independently; there is no priority rule where one field displaces the other. A recognised payment reference is stored in a separate field (PaymentID) and does not overwrite the invoice number. Invoice number and payment reference each land in their own field in the e-invoice.

Exception — no invoice number available: if a document contains a payment reference but no invoice number, the IDR uses the payment reference as the invoice number. This occurs, for example, with a CJIB fine or a Tax Authority assessment: on those documents the payment reference is unique and no regular invoice number is present.

With the Professional subscription, the recognised IBAN is compared against previously verified IBAN numbers in the verification store. If the IBAN on a new invoice differs from what was previously recorded, the system generates a warning. This helps detect changed bank details or potential phantom invoices.

Want to know which fields the IDR recognises? Read Which fields does the IDR recognise?.