If a large client has recently asked you to include a GLN number on your invoice, and your accounting software or team has no idea what that is, you are not alone. This is one of the most common friction points in B2B e-invoicing today, and it is costing businesses real money in delayed payments and rejected invoices.
Below we explain what GLN numbers are, why more organisations require them, where most software falls short, and what Cashfeed now does differently.
What is a GLN number?
A GLN — Global Location Number — is a 13-digit identifier managed by GS1, the international body behind supply chain standards. It uniquely identifies a specific location or organisational unit: a warehouse, a head office, a purchasing department, a billing address etc.
The key distinction: a VAT number identifies a company as a legal entity. A GLN identifies a specific location or department within that company. Both can appear on the same invoice, they serve different purposes and are not interchangeable.
It’s typically used by large organisations and most larger organisations even have multiple GLNs, one per site, per purchasing department, or per invoicing entity. A logistics company might have one GLN for its central warehouse, a separate one for its regional distribution centre, and another for the accounts payable team that actually processes supplier invoices. Each of those is a distinct destination in their system. In structured e-invoicing formats like Peppol UBL and EDIFACT, the GLN tells the receiving system exactly where to route the document for automated processing, without any human involvement.
In short: GLN replaces informal, self-invented location references with an internationally standardised identifier. That is what makes fully automated invoice processing possible. |
|---|
Why more clients are requiring GLN numbers
GLN is not a government mandate in most countries, it is driven by large private organisations automating their accounts payable. When a retailer, logistics platform, or industrial group migrates to e-invoicing or upgrades its ERP, GLN compliance becomes a hard requirement for every supplier in its network. Your client decides; you adapt.
Two developments are making this more common:
Peppol and structured e-invoicing are becoming the default
XML-based invoices leave no room for free-text location fields. GLN is a widely adopted location identifier in European e-invoicing formats, including the EU invoice standard EN 16931, and it is commonly used as a party identifier in Peppol networks across Europe.
Invoice processing is now fully automated
Large organisations process thousands of invoices without human review. A missing or incorrect GLN does not trigger a phone call or a helpful reply. It triggers an automatic rejection, often with no feedback sent back to the supplier. The first sign that something went wrong is a late payment, or silence.
Where most invoicing software gets this wrong
Most accounting software supports Peppol today. That is the baseline. The real problem is GLN, and here the gaps are consistent and significant.
The limitations fall into two areas:
Data model
GLN can only be stored at the customer level, not per location or department
Multiple GLNs per customer are not supported, even though that is standard for any large organisation
Export and validation
The GLN field is a free-text field that does not export correctly into the XML structure
The number ends up in the wrong XML element and is unrecognisable to the receiving system
No validation before sending: the software exports the file without flagging that the GLN is missing or incorrectly placed
The result is a silent failure. The invoice leaves your system. The Peppol file looks fine on your end. On the buyer's side, the GLN is not found or not valid, and the invoice is rejected. You find out weeks later, not through an error message, but because payment simply does not arrive.
For clients on net-30 or net-60 payment terms, a single rejected invoice can push payment back by 4 to 8 weeks. There is no automatic correction, no alert, and often no explanation. You have to chase it down yourself: identify the rejection, fix the file, resubmit, and follow up with a purchasing department that processes hundreds of invoices a week and does not prioritise yours.
Multiply that across multiple clients with GLN requirements, and you have a structural cash flow problem rooted in a data field. Longer term, suppliers who repeatedly submit technically incorrect invoices tend to get flagged internally, which surfaces during contract renewals and procurement evaluations.
How Cashfeed handles this
GLN support in Cashfeed is not an add-on or a workaround built after the fact. It is part of the core data model.
Multiple GLNs per customer are fully supported, e.g. for different customers, locations, and departments
When generating a Peppol invoice, the GLN is automatically placed in the correct XML fields
Full compatibility with Peppol UBL 2.1, EN 16931, and other European e-invoicing standards
Validation before sending: if the GLN is missing or incorrectly configured, you are notified before the file goes out
No manual steps. No silent export errors. Invoices arrive correctly structured the first time, which means fewer rejections, faster payments, and correct routing to the right department on the buyer's side.
Frequently asked questions
What is the difference between a GLN and a VAT number?
Can one company have multiple GLN numbers?
Why is my client suddenly asking for a GLN?
Does Peppol require a GLN?
GLN issues are easier to fix before the first rejection
Have a chat with us. We will look at your current setup and show you exactly how Cashfeed handles GLN for your clients.
