In the construction sector, clients and contractors often work with a G-account (blocked account). This is a bank account where part of the invoice amount is deposited, specifically intended for the payment of payroll taxes and VAT. The G-account extension on NLCIUS makes it possible to include this payment split in an e-invoice.

When a contractor outsources work to a subcontractor, the client is in certain cases jointly liable (chain liability) for the payment of payroll taxes and VAT by the subcontractor. By depositing part of the invoice amount directly into the subcontractor's G-account, the client reduces this risk. The tax authorities can then use the balance in the G-account for the payment of taxes due.

In practice, the client pays the invoice in two parts: an amount to the regular bank account and an amount to the G-account.

The G-account extension is an addition to the standard NLCIUS format. It has its own DocumentTypeId that identifies the extension on the Peppol network:

urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:nen.nl:nlcius:v1.0#conformant#urn:fdc:nen.nl:gaccount:v1.0::2.1

Note the difference from the standard NLCIUS DocumentTypeId: the G-account extension adds #conformant#urn:fdc:nen.nl:gaccount:v1.0 after the NLCIUS designation. This makes it immediately recognisable for receiving systems that the invoice contains a G-account payment split.

The G-account is included as a separate payment component (PaymentMeans) in the UBL invoice. The invoice therefore contains two payment instructions:

1. Regular payment: the portion of the invoice amount going to the regular bank account.
2. G-account payment: the portion going to the blocked account, intended for payroll taxes and VAT.

The receiver can see in the invoice exactly how much should be transferred to which account. This makes invoice processing in the construction sector transparent and verifiable.

Not every receiver supports the G-account extension. The PSB handles this automatically:

• Receiver supports the extension: one invoice is sent with the G-account DocumentTypeId and the payment split included in the invoice.
• Receiver does not support the extension: two separate invoices are sent, each with its own payment instruction. The receiver then receives one invoice for the regular portion and one invoice for the G-account portion.

Whether a receiver supports the extension is determined by the SMP registration. If the G-account DocumentTypeId is not registered in the receiver's SMP, the PSB automatically chooses the two-invoice variant.

The G-account extension was specifically developed for the Dutch construction sector, where chain liability is an important topic. In combination with other construction sector standards such as DICO/SALES005 (for packing slips and maintenance orders) and GLN codes (for addressing construction parties), eConnect offers a complete package for electronic document exchange in construction.

Tip: Do you work in construction and want to send G-account invoices? Check with your software vendor whether the G-account DocumentTypeId is supported. The eConnect PSB validates and routes the invoice automatically to the correct format for the receiver.

Do you have questions about the G-account extension or want to check whether your invoices are correctly formatted? Use the free eConnect Validator or contact support.

• NLCIUS: the Dutch e-invoice standard
• DocumentType IDs and code lists
• Reverse charge VAT: codes K and AE
• Peppol BIS Billing V3