G-account in a UBL invoice

Including a G-account number in a UBL invoice: the NLCIUS G-account extension, XML structure and use in construction.

In the construction, temporary staffing and cleaning industries, the G-account (blocked account) is a widely used instrument. A portion of the invoice amount is transferred to a blocked bank account from which only payroll taxes and social security contributions may be paid. This protects the client against liability for unpaid taxes by the contractor (chain liability under the Dutch Chain Liability Act).

To automate this process, the invoice must contain the G-account number and the amount to be transferred to the G-account. The standard UBL does not have a place for this. That is why the NLCIUS G-account extension exists.

The NLCIUS G-account extension

The NLCIUS G-account extension (officially: NLCIUS-GAC) is a Dutch extension to the NLCIUS profile, specifically designed to include G-account details in a UBL invoice. The extension adds a separate payment block alongside the regular payment.

The profile has its own CustomizationID:

urn:cen.eu:en16931:2017#compliant#urn:fdc:nen.nl:nlcius:v1.0#conformant#urn:fdc:nen.nl:gaccount:v1.0

eConnect automatically recognises this profile and processes the G-account details when routing the invoice.

XML structure

The G-account information is included via a UBLExtension in the UBLExtensions block at the top of the invoice. The extension contains a separate PaymentMeans element with the G-account number and amount:

<ext:UBLExtensions>
  <ext:UBLExtension>
    <ext:ExtensionContent>
      <nlgac:GAccountExtension
        xmlns:nlgac="urn:fdc:nen.nl:gaccount:v1.0">
        <cac:PaymentMeans>
          <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
          <cac:PayeeFinancialAccount>
            <cbc:ID>NL86INGB0002445588</cbc:ID>
            <cbc:Name>G-account Construction Co. B.V.</cbc:Name>
          </cac:PayeeFinancialAccount>
        </cac:PaymentMeans>
        <cbc:PrepaidAmount currencyID="EUR">400.00</cbc:PrepaidAmount>
      </nlgac:GAccountExtension>
    </ext:ExtensionContent>
  </ext:UBLExtension>
</ext:UBLExtensions>

In this example, 400 euros of the invoice amount must be transferred to the G-account. The remaining amount goes to the regular bank account number stated in the standard PaymentMeans element.

How the payment works

With a G-account invoice, the buyer pays in two parts:

  1. The G-account amount to the G-account number from the extension
  2. The remaining amount to the regular bank account number

The invoice itself contains the full amount in PayableAmount. The split is informational: the buyer knows how much to transfer to which account number. In the LegalMonetaryTotal, the G-account amount can also be included as PrepaidAmount, making the remaining amount visible in PayableRoundingAmount or an adjusted PayableAmount. The exact implementation varies per software package.

Tip: if you invoice in the construction sector via eConnect, check whether your software package supports the NLCIUS G-account extension. If not, eConnect can include the G-account information when you provide the G-account number and amount via the API or the platform.

G-account and DICO

In the construction sector, invoices are often exchanged in the DICO format (Digital Communication in construction). DICO invoices include a standard field for the G-account. When eConnect transforms a DICO invoice to UBL, the G-account information is automatically carried over into the NLCIUS G-account extension, so the information is not lost when switching formats.

Frequently asked questions

Is the G-account mandatory?

No. The G-account is optional and is mainly used in sectors with chain liability. Many construction companies and staffing organisations use it, but it is not a legal requirement.

Can I include a G-account in a regular BIS Billing V3 profile?

Not directly. The G-account extension is specific to NLCIUS. If you use the standard Peppol BIS Billing V3 profile without NLCIUS, there is no standardised place for G-account information. In that case, you could include the G-account number as a second PaymentMeans, but this is not standardised and is not recognised by all receivers.

How does the receiver know it is a G-account invoice?

The CustomizationID of the invoice contains the G-account extension identifier. Receiving software that supports this profile automatically recognises the extension and displays the G-account information to the user.

Check invoice