Iceland Public-Sector E-Invoicing: TS-236, Peppol, Skuffan

For Iceland public sector e-invoicing, the safe starting point is this: if you are invoicing an Icelandic public entity, you should expect to send a structured electronic XML invoice, not a PDF attachment by email. Official guidance ties the state requirement to 1 January 2020, and in practice suppliers need invoice data that fits TS-236 within the EN 16931 and Peppol BIS framework. Smaller suppliers that do not send directly from their own accounting system may use Skuffan as the portal route.

That matters because Icelandic public procurement guidance is focused on whether your invoice can move through the right validation and delivery path, not just whether it looks correct on screen. If you need a refresher on what structured e-invoicing means compared with PDF billing, this is one of the clearest cases where the distinction affects whether a buyer will accept the invoice at all.

The clearest high-level statement comes from HSN's notice on Iceland's public-sector e-invoicing requirement, which says that from 1 January 2020 all purchases by the Icelandic state must be accompanied by electronic invoices, and that smaller parties can use a free portal when they are not sending from their own accounting system. That gives suppliers two immediate answers: the public-sector requirement is real, and the expected format is an electronic invoice route rather than a PDF-by-email process.

It is also worth separating this public-buyer workflow from private commercial invoicing more broadly. The issue here is Iceland B2G e-invoicing and public-sector supplier compliance, not a claim that every invoice in Icelandic business must follow the same route. If your customer is a ministry, hospital, municipality, or another public institution, you need to confirm the invoice standard and submission path they expect before you send anything.

---

How TS-236 Fits With EN 16931 And Peppol BIS Billing 3.0

The part that confuses many suppliers is seeing several standards mentioned on the same buyer page. The practical way to read them is as layers of the same compliance picture. TS-236 is the Icelandic public-sector e-invoice standard used in local guidance. CEN EN 16931 is the European semantic model that defines the core invoice data structure. Peppol BIS Billing 3.0 is the implementation framework many public-sector invoice exchanges use to move that structured data between sender and receiver systems.

So when an Icelandic public institution says your invoice must comply with TS-236, EN 16931, and Peppol BIS, it is not usually asking you to choose among three separate formats. It is signaling that your invoice needs the right structured content, the right semantic model, and a transport-ready implementation that can pass validation in the receiving workflow. That is the real meaning of the Iceland TS-236 standard for suppliers: your invoice data has to be structured in a way Icelandic public buyers and their routing partners can actually process.

This is also why a generic PDF invoice does not solve the problem. A PDF may show the same values to a human reader, but it does not automatically supply the machine-readable invoice structure expected in an Iceland PEPPOL invoice guide or public-sector validation flow. Public buyers are not looking only for a visible invoice. They are looking for electronic invoice data that can be checked, routed, and booked without manual re-entry.

If you have worked with other Nordic or European public-sector invoice rules, the pattern will feel familiar even if Iceland's terminology is different. Our guide to Finland's Finvoice, TEAPPSXML, and Peppol routing rules shows the same broader principle: local requirements often sit on top of a structured e-invoicing model rather than replacing it.

Which Submission Route Should You Use, Access Point, Broker, Or Skuffan

Once the invoice content is in the right format, the next question is how you actually send it. In Iceland, the answer usually comes down to whether you already issue structured invoices from your accounting or ERP system, or whether you need a lighter submission path.

If your finance system already supports electronic invoicing, you will typically send through an access point, message server, or broker that can route the invoice into the buyer's receiving setup. Different public institutions may describe the route slightly differently, but the operating idea is the same: the invoice travels through an approved electronic channel, not as a file attached to a normal email.

If you do not have that direct-system setup, Skuffan is the practical fallback mentioned in Icelandic public guidance for smaller suppliers. In other words, the Iceland Skuffan invoice portal is relevant when you still need to meet the public-sector electronic invoice requirement but are not sending from your own invoicing software. That makes Skuffan a route choice, not a separate invoice standard.

This distinction matters. A supplier can have the right TS-236-aligned invoice content but still fail if it is sent through the wrong channel. The reverse is also true: choosing the right route does not fix a non-compliant invoice structure. Think of format and delivery as two linked controls that both have to line up before the buyer can accept the invoice.

For comparison, Luxembourg's public-sector Peppol and portal workflow shows a similar public-sector pattern where suppliers may need to choose between direct network routing and a portal-based submission route depending on their setup. Iceland follows the same logic, even though the local names and validation details differ.

---

The Validation Details That Commonly Trigger Rejection

The biggest gap in most high-level summaries is that they stop at "use e-invoicing" and never explain what actually causes a rejection. In Iceland, the trouble often starts with fields that look minor but are treated as validation-critical by buyer systems and Peppol rule checks.

Here are the checks suppliers should treat as mandatory:

• Buyer references and identifiers: Make sure the invoice contains the buyer information, reference numbers, and routing details the receiving institution expects. Public-sector workflows often depend on these fields to reach the right department or cost center.
• Due-date consistency: If your invoice includes EINDAGI, the date format and relationship to the invoice due date matter. Iceland-specific Peppol rules require the EINDAGI value to be in the correct date format, require a due date to exist, and require the EINDAGI date to be the same as or later than the due date.
• Payment details: Certain Iceland-specific payment-method scenarios require a 12-digit account ID. If your payment information does not match the expected rule set, the invoice can fail validation even when the totals are correct.
• Address completeness: Iceland-specific rules also include address expectations in some Icelandic buyer and seller combinations, including street name and postal code completeness.

The important operational point is that these are not cosmetic details. They are part of the Iceland PEPPOL BIS invoice rules that determine whether the invoice can move through the buyer's process. Suppliers should therefore review due dates, payment fields, and buyer references as carefully as they review amounts, tax, and invoice numbers.

What Foreign Suppliers Should Confirm Before Invoicing An Icelandic Public Entity

Foreign suppliers often understand e-invoicing in general but still run into trouble because they assume the receiving workflow will work like it does in their home market. That is a risky assumption in Icelandic public procurement.

Before sending your first invoice, confirm the receiving body's exact submission route, the buyer reference or department information it needs, and whether it expects you to send through a specific provider or portal path. Also check whether the institution publishes any extra supplier instructions beyond the national-level guidance. The broad rules explain the framework, but many operational details still live on individual institution pages, which is why Iceland public procurement e-invoicing is often more operationally specific than it first appears.

It is especially important not to rely on a PDF process that works elsewhere. For Iceland electronic invoice requirements, the question is not whether a human at the buyer can open the file. The question is whether your invoice can pass the structured validation and routing workflow that public buyers use. That is why cross-border suppliers should verify route, format, and reference data before they submit a live invoice.

If you are invoicing from outside Iceland, also confirm bank details, tax treatment, and any language or naming conventions the buyer expects on first submission. Those are routine cross-border controls, but in a public-sector workflow they can quickly become payment-delay issues if they are left ambiguous.

---

A Practical Pre-Send Checklist For Icelandic Public-Sector E-Invoices

Use this checklist before you submit an invoice to an Icelandic public buyer:

• Confirm that the buyer is a public entity covered by the electronic invoice workflow, and do not assume a private-sector invoice process will apply.
• Send a structured electronic invoice, not a PDF attachment, unless the buyer has given written instructions for an exception.
• Make sure the invoice content matches the TS-236, EN 16931, and Peppol-aligned requirements used in the buyer's workflow.
• Choose the right route: send through your accounting-system connection, access point, message server, or broker if available, or use Skuffan if you are a smaller supplier without your own direct-system setup.
• Check buyer references, department or cost-center details, and any institution-specific routing identifiers before sending.
• Review due-date and payment fields carefully, especially if your invoice includes EINDAGI or a payment method that depends on a 12-digit account ID.
• Confirm address completeness and any other Iceland-specific validation fields that could block acceptance.
• For first-time or foreign suppliers, verify the receiving institution's local instructions before pressing send.

That short review captures the real supplier workflow behind Iceland public sector e-invoicing: right buyer scope, right invoice structure, right route, and right validation details.