Luxembourg Public-Sector E-Invoicing: Peppol and MyGuichet

Guide to Luxembourg public-sector e-invoicing through Peppol or MyGuichet.lu, covering scope, compliant formats, foreign-supplier steps, and corrections.

Published
Updated
Reading Time
10 min
Topics:
Tax & ComplianceEUGovernmentLuxembourgPeppolMyGuichetpublic procurement e-invoicing

Luxembourg public sector e-invoicing means suppliers invoicing public bodies must send compliant electronic invoices or credit notes through one of two authorized channels: Peppol or MyGuichet.lu. A PDF attached to an email is not enough because Luxembourg expects a structured electronic invoice that the receiving system can process. In practice, Peppol is the standard route for organizations already set up for electronic exchange, while MyGuichet.lu acts as the fallback for occasional or foreign suppliers that need manual entry or portal-based submission. Some MyGuichet procedures also rely on a one-time code from the receiving authority plus proof that the invoice relates to a real contractual relationship.

That is the core answer most searchers need first. If you already exchange invoices through Peppol, that is usually the cleanest route. If you do not, the next question is whether the public body has directed you to one of the MyGuichet.lu procedures for manual entry or compliant-file upload. Either way, the rule is about public-sector transmission workflow, not a general statement that every invoice in Luxembourg must go through the same system.

The practical issue is route selection. Suppliers working under public procurement contracts or concession contracts need to know whether they are in scope, which channel the authority expects, what file format counts as compliant, and what to do if they are an occasional or foreign supplier without a Peppol connection. Credit notes sit inside the same framework, so troubleshooting does not start only when something goes wrong.

The rest of this guide breaks the process into the decision points that matter in real work: who has to comply, when to choose Peppol over MyGuichet.lu, what structured format is expected, how unauthenticated portal submissions work, and how to handle corrections if an invoice is rejected or sent with mistakes.


Who has to use it, and since when

For suppliers invoicing Luxembourg public bodies, the key date is 18 March 2023. Since then, businesses supplying those entities have had to issue compliant electronic invoices regardless of invoice amount. The point is not that Luxembourg moved all domestic invoicing into one national clearance system. The rule is narrower and more operational: if you are billing an in-scope public entity, you must use the authorized e-invoicing framework for that transaction.

That scope matters because many suppliers arrive here after assuming the answer depends only on tax status or company location. It does not. A foreign supplier can still fall into scope if it is invoicing a Luxembourg public body under a public procurement contract or a concession contract. The deciding factor is the nature of the customer relationship and the public-sector procurement context, not whether the supplier is locally established.

It is also useful to separate invoice content from invoice transmission. Even when the delivery channel changes, the underlying invoice still needs the correct commercial and tax information. If you need a refresher on the Luxembourg VAT invoice fields that still matter on the underlying invoice, check those first, then return to the transmission workflow in this guide.

The official guidance published through Luxembourg's public e-invoicing resources, including material under the Ministry for Digitalisation umbrella, is consistent on the practical takeaway: once an invoice is in scope, ad hoc email delivery is not a compliant fallback. That is why the next step is not "can I send a PDF anyway?" but "which authorized route should I use?"

When to use Peppol and when MyGuichet makes more sense

Peppol is the preferred route when your organization already exchanges structured invoices electronically. It is the standard network Luxembourg expects suppliers to use for routine, repeatable public-sector invoicing because it supports automated delivery and receipt through connected access points. If your finance team, ERP, or service provider is already Peppol-enabled, there is usually little reason to move away from that workflow for Luxembourg public bodies.

MyGuichet.lu fills the gap for suppliers that are not connected to Peppol or only need to invoice a Luxembourg authority occasionally. In that sense, it is a practical fallback rather than a competing standard. The portal gives suppliers a way to submit through authorized Luxembourg procedures without building a full Peppol setup just to send one or two invoices.

The cleanest decision framework looks like this:

  • Use Peppol if you already have a working Peppol connection and want a normal structured-invoice workflow.
  • Use MyGuichet.lu if the public body has directed you to its portal-based procedure and you need manual entry or controlled upload.
  • Do not confuse route choice with format compliance. Changing the channel does not remove the requirement to send a compliant structured invoice.

This also helps explain why Luxembourg's model looks familiar if you have worked with another EU public-sector e-invoicing model that uses Peppol routing or seen how another Peppol-based public-sector invoicing rollout is structured. A different variation appears in Estonia's buyer-requested e-invoice regime and recipient-register workflow, where the trigger is not only public procurement but also whether the buyer is registered to receive structured invoices. The network is the default operating path, while the local portal handles exceptions and occasional-supplier cases.

For most teams, the real question is not whether one route is universally better. It is whether your current setup supports Peppol already, whether the receiving authority has given you a MyGuichet instruction set, and whether you need a one-off submission path instead of an ongoing automated exchange model.


What counts as a compliant electronic invoice

A compliant electronic invoice in this context is a structured electronic file. That is the point many suppliers miss. A PDF can display the invoice to a human reader, but it does not automatically satisfy the machine-readable requirement built into Luxembourg's public-sector e-invoicing process. The same problem applies to Word documents, spreadsheet exports, or scanned images emailed to the authority as if they were equivalent to an e-invoice.

In practice, the safest baseline is an invoice that aligns with the European structured-invoice standard EN 16931 and can move cleanly through the Peppol ecosystem. Luxembourg's guidance is especially clear about the operational preference here. Luxembourg's official FAQ on Peppol invoice formats says Peppol BIS Billing 3.0 in XML UBL is the standard electronic invoice used in Peppol and the only standard that all Peppol access points are required to receive and process.

That does not mean Peppol BIS Billing 3.0 is the only structured format a standards discussion could mention. In the wider EN 16931 landscape, you will also see references to XML UBL more broadly and to UN/CEFACT CII. But suppliers need a practical answer, not a standards seminar. If your goal is to send an invoice that the Luxembourg public-sector workflow can receive with minimal friction, Peppol BIS Billing 3.0 in UBL is usually the safest operational choice.

The reason format matters is simple: the receiving system needs to parse fields and process the invoice data, not merely show a document image on screen. Once you frame the issue that way, the "why is a PDF not enough?" question answers itself. A PDF may still exist as a visual representation or attachment in some business processes, but it is not the structured electronic invoice Luxembourg expects for compliant public-sector transmission.

How occasional and foreign suppliers use MyGuichet.lu

MyGuichet.lu matters most when a supplier is not already connected to Peppol or only needs to invoice a Luxembourg public body from time to time. That makes it especially relevant for foreign suppliers, smaller vendors, or project-based contractors that do not want to stand up a recurring Peppol workflow for a limited number of invoices.

At a practical level, the portal is designed to offer authorized fallback procedures. Depending on the route the authority points you to, that can mean entering invoice information manually or submitting an already compliant electronic invoice file through the portal. The important distinction is that MyGuichet.lu is a submission route, not an automatic converter that makes any document compliant after the fact.

One of the more distinctive Luxembourg features is the unauthenticated path. In that flow, the receiving public body provides a one-time code that lets the supplier access the relevant procedure without a full Luxembourg login setup. The authority may also require a purchase order reference or other proof of the contractual relationship so it can connect the submission to the correct public procurement contract or concession contract. That is why foreign suppliers should not wait until the last minute to gather supporting identifiers.

If you are outside Luxembourg, the practical checklist is straightforward. Confirm that the public body accepts the MyGuichet.lu procedure you intend to use. Confirm whether you need a one-time code in advance. Prepare the contract or purchase-order evidence the authority expects. Then make sure the file or data you submit still meets the structured invoice requirement. MyGuichet makes occasional access easier, but it does not remove the compliance conditions behind the invoice.


Credit notes, rejected invoices, and the mistakes that cause delays

Credit notes belong to the same framework as invoices. If you need to reverse or adjust a public-sector invoice, the credit note should move through the same authorized channel, meaning Peppol if that is your live exchange route or the relevant MyGuichet.lu procedure if that is how the authority instructed you to submit. Treating credit notes as informal side documents is one of the quickest ways to create reconciliation problems.

The next common misconception is that a mistaken invoice can always be edited in place after submission. In practice, suppliers usually need to follow the receiving body's correction or replacement process. That may mean cancellation, rejection handling, or resubmission steps rather than opening the original submission and changing a few fields. The exact administrative path can vary by authority, but the operating principle is the same: once the structured invoice has been transmitted, corrections need to follow the official workflow.

If a submission is rejected, read the authority's reason before doing anything else. That tells you whether the problem is route choice, file structure, missing contract references, or incorrect invoice content, and it helps you decide whether you need a corrected replacement invoice, a credit note, or a fresh compliant submission.

The errors that most often delay transmission or acceptance are usually ordinary process mistakes:

  • Sending a PDF by email and assuming it counts as an e-invoice.
  • Choosing MyGuichet.lu when a live Peppol route already exists, or choosing Peppol when the authority has directed you to a portal-based fallback.
  • Uploading or generating a file that is not actually a compliant structured invoice format.
  • Missing the one-time code, purchase order reference, or proof-of-relationship step in an unauthenticated MyGuichet submission.
  • Submitting invoice details that do not line up with the contract, concession, or authority records.

Before you send or resend anything, run a short check: confirm the customer is an in-scope Luxembourg public body, choose the correct route, validate that the invoice or credit note is in a structured format, and gather the identifiers the authority expects to see. That short review prevents most of the avoidable failures that turn a straightforward submission into a multi-step correction exercise.

About the author

DH

David Harding

Founder, Invoice Data Extraction

David Harding is the founder of Invoice Data Extraction and a software developer with experience building finance-related systems. He oversees the product and the site's editorial process, with a focus on practical invoice workflows, document automation, and software-specific processing guidance.

Editorial process

This page is reviewed as part of Invoice Data Extraction's editorial process.

If this page discusses tax, legal, or regulatory requirements, treat it as general information only and confirm current requirements with official guidance before acting. The updated date shown above is the latest editorial review date for this page.

Continue Reading

Invoice Data Extraction

Extract data from invoices and financial documents to structured spreadsheets. 50 free pages every month — no credit card required.

Try It Free