B2G Commerce: Selling to Public Sector Buyers

Public authorities, hospitals, universities, school boards and municipal utilities buy at a scale most mid-sized suppliers rarely target seriously. In 2024 alone, 199,334 public contracts and concessions worth EUR 135.2 billion were awarded in Germany (Federal Statistical Office, procurement statistics). Getting into this segment is not a sales problem, it is a process problem. Suppliers that map the formal requirements of public procurement into their shop sell against predictable call-offs, multi-year contract terms and far less price pressure than in the open market. This article sets out what your B2B shop has to be able to do - from the Leitweg-ID as a mandatory field to an accessible ordering interface.

Public sector buying is a B2B segment with its own rules

Official German procurement statistics show a market that e-commerce teams rarely address strategically: 199,334 reported awards worth EUR 135.2 billion in 2024 (Federal Statistical Office, procurement statistics), reported by 11,524 registered contracting bodies as of 31 December 2024 (Federal Statistical Office, procurement statistics). Because reporting duties only start above certain thresholds, actual purchasing volume sits above these figures - the statistics capture the documented core, not total demand.

Across Europe the scale is even clearer. The European Commission puts the number of public buyers in the EU at more than 250,000 and annual procurement spending at around 14 percent of EU GDP, roughly two trillion euros (European Commission, Public Procurement). For a supplier this means there is barely a product category that is not purchased publicly somewhere - from office and laboratory supplies through workwear and hygiene to IT accessories, workshop materials and cleaning products.

The decisive difference from the open market is the contract form. Recurring demand is bundled and awarded as framework contracts running over several years, from which individual public entities then call off. Once listed in such a contract, you are no longer selling against a daily price comparison but within a set of terms negotiated once.

• Federal, state and municipal authorities - from a federal agency to the regulatory office of a mid-sized town
• Hospitals and university clinics - often with their own purchasing groups and highly structured catalogue processes
• Universities and research institutes - with decentralised requesters in institutes and departments
• School boards - purchasing for many sites from a single framework contract
• Municipal utilities - energy, waste, public pools and works yards with high recurring material demand

Leitweg-ID: the mandatory field invoices fail on

The Leitweg-ID (routing identification number) is the address that lets an electronic invoice find its recipient inside the public administration network. The German E-Invoicing Ordinance lists it explicitly as a mandatory invoice element in section 5 - together with bank details, payment terms and a De-Mail or email address (E-Rechnungsverordnung, E-RechV). In the XRechnung data model it belongs in field BT-10, the buyer reference (KoSIT, XRechnung standard).

Its structure has three parts: a coarse address of up to twelve digits, an optional fine address of up to 30 digits and a two-digit check digit (KoSIT, Leitweg-ID specification). For the federal administration the coarse addresses are standardised: 991 identifies direct federal administration, 992 indirect federal administration via the OZG-compliant invoice receipt platform, and 993 recipients running their own solution (KoSIT, Leitweg-ID specification). States and municipalities issue their own numbers following the same pattern.

This is where the first concrete shop requirement sits. The Leitweg-ID must not be a by-product of a comment box; it needs to exist as its own validated data field, end to end from the customer account through to invoice output:

1. A dedicated field, not free text: the Leitweg-ID belongs in the customer account, the cart and the order confirmation as a named field - not in a generic comment box nobody can parse later.
2. Format checking on input: character set, segment lengths and the two-digit check digit can be validated in the front end. The check digit is the most effective protection against transposed digits because it catches a large share of typical typing errors (KoSIT, Leitweg-ID specification).
3. Storage per public entity: a buyer rarely has just one Leitweg-ID. Ministry, subordinate agency and individual departments may use different fine addresses - the shop has to manage several IDs per account and assign the right one to each requester.
4. Pre-filling at checkout: when someone orders for their own entity, the stored ID is pre-filled and only needs confirming. That reduces input errors far more than any downstream check.
5. Passing it through to the invoice: the ID has to travel from the order into field BT-10 of the generated XRechnung without manual re-keying.

Passing purchase order number and cost centre through cleanly

Besides the Leitweg-ID, section 5 of the E-Invoicing Ordinance names two further items an electronic invoice has to contain if they were supplied when the order was placed: the supplier number and the purchase order number (E-Rechnungsverordnung, E-RechV). It reads like a footnote but is in practice the most common cause of delayed payment. An invoice without an order reference cannot be matched automatically and ends up in manual clarification - with consequences for payment terms and supplier scoring.

Technically this means these fields belong not only in the checkout but in the order data model, the order confirmation, the delivery note and the invoice document. Every station where a person retypes a value is a source of error. Generating and transmitting the invoice documents themselves belongs outside the request cycle in asynchronous jobs - our article on Shopware message queue and worker operation describes how to run that reliably in production.

XRechnung instead of a PDF attachment: only the B2G essentials

The legal basis comes from Brussels. Directive 2014/55/EU on electronic invoicing in public procurement of 16 April 2014 obliged member states to introduce a European standard for the semantic data model of the core invoice elements (EUR-Lex, Directive 2014/55/EU). Central contracting authorities had to apply it within 18 months of the standard being published, while sub-central authorities were allowed to defer application by up to 30 months (EUR-Lex, Directive 2014/55/EU). The result is the standard EN 16931, covering core elements such as process and invoice identifiers, seller and buyer information, delivery details, payment information, invoice line items and VAT breakdown (EUR-Lex, Directive 2014/55/EU).

Germany implements this through the E-Invoicing Ordinance: XRechnung is in principle the data exchange standard to use, transmission runs via the federal administration portal, and every invoice passes an automated formal check (E-Rechnungsverordnung, E-RechV). The standard is maintained by KoSIT, the coordination office for IT standards at the Senator for Finance in Bremen. The current version is XRechnung 3.0.2; the winter 2025/2026 bugfix release has been in force since 31 January 2026 (KoSIT, XRechnung standard). For suppliers this means invoice output has to be versionable, because validation rules evolve on a published schedule.

The obligations came into force in stages. The ordinance has applied since 27 November 2018, for sub-central and sector contracting authorities since 27 November 2019, and since 27 November 2020 invoice issuers have been obliged to transmit electronically (section 11, E-Rechnungsverordnung). The federal administration provides two central receipt platforms for this - the central invoice receipt platform of the federal government and the OZG-compliant invoice receipt platform (Federal Procurement Office, Kaufhaus des Bundes).

We cover formats, validation and transmission routes in depth elsewhere: in our article on e-invoicing requirements for online shops, in the overview of PEPPOL eInvoicing for B2B shops and on our service page for ZUGFeRD and XRechnung. Only the B2G core matters here: towards public buyers, a PDF in an email attachment is not a structured invoice data set but a document somebody has to retype.

A PDF is a picture of an invoice. An XRechnung is the invoice.

XICTRON development team

Catalogues and punchout: getting into the procurement systems

Public requesters rarely work directly in a single supplier's shop front end. They order from a procurement system in which all listed contracts sit side by side and in which approval, budget and posting are already anchored. Two routes lead in there: catalogue provision as a structured file, and punchout as a live connection into your shop.

• Catalogue export: the buyer receives the contractually agreed range as a structured file with article numbers, contract prices, units of measure, classification and product-related mandatory information. Catalogues have to be versioned and delivered with a validity period because they are frozen inside the procurement system.
• Punchout session: the requester jumps from their system into your shop, sees only their contract range at contract prices and returns the cart in structured form to their own system - approval and ordering then happen there.
• Classification: procurement works with CPV codes, and catalogues frequently add a commodity classification on top. Without clean per-article classification a catalogue cannot be loaded at all.
• Range cut: a contract rarely covers the entire shop range. Which articles a buyer sees has to be derived from the contract - the basics are in our article on customer-specific catalogues in the B2B shop.

The technical detail of punchout protocols - setup request, session handling, cart return - is described at length in our article on punchout catalogues with OCI and cXML. The same mechanics apply in B2G, with one addition: the cart return has to carry the procurement-specific references so that contract number and cost centre reappear in the invoice later.

Framework contract prices and call-offs per public entity

In B2G the price is not a property of the article but of the combination of article, contract and public entity. The same box of copier paper can be supplied to a state authority under framework contract A and to a hospital under framework contract B at different terms - and both prices are contractually fixed rather than negotiable.

Technically this calls for a pricing model with several layers: list price, contract price and, where required, an entity-specific deviation, each with a validity period and price adjustment clause. We described the fundamentals of multi-level B2B pricing in our article on B2B pricing strategies in e-commerce; in B2G there is the added point that any deviation from the contract price has to be justified.

1. Contract number and term per contract, including extension options and end date
2. Range cut - which articles fall under the contract and which explicitly do not
3. Price list with validity and documented price adjustment logic instead of manual upkeep
4. Call-off budget or volume quota with a visible remaining value so overruns surface before ordering
5. Authorised entities - who may call off from the contract and who may not
6. Call-off history and reporting per contract, exportable for the buyer's contract management

Customer-specific prices and HTTP caching are technically in tension: rendering every page dynamically costs performance, while caching too coarsely shows wrong prices. Our article on the Shopware cache rework for logged-in customers shows how the newer caching model resolves this.

Approval and budget logic on the requester side

In a public authority the person ordering is rarely the person deciding. A case worker builds the cart, the unit head approves, the budget office checks funding, and invoice verification closes the process. A shop that only knows one account per customer cannot represent this - and forces the buyer into side processes in spreadsheets and email.

• Roles per account: requester, approver and invoice recipient are different people with different rights
• Value limits per role: below a threshold the case worker orders directly, above it one or more approval stages apply
• Budget pot per cost centre with a visible remaining value and a block when it is exceeded
• Deputy rules for holidays and sick leave so cases do not stall
• Audit logging of every approval with timestamp and person - this is audit-relevant in the public sector

We described implementing such approval chains in the shop in detail in our article on B2B order approval workflows. The payment method matters too: public buyers pay on account almost without exception, which requires solid credit limit and payment term management - see purchase on account with credit limits in B2B.

Credentials: prequalification and self-declarations in onboarding

Before a public buyer orders, it vets the supplier. Suitability evidence, self-declarations and prequalification numbers are standard in every procurement procedure. This matters for the shop because these documents are not a one-off: they have to be maintained, and an expired certificate can effectively suspend a running contract.

• Prequalification number and its validity period
• Clearance certificates from the tax office and social insurance institutions
• Current commercial register extract or trade registration
• Self-declarations on minimum wage, collective agreement compliance and exclusion grounds
• Proof of business liability insurance including coverage amounts
• Supply chain and sustainability information where required by the specification
• Accessibility statement for the digital ordering interface being offered

In practice this means the customer account needs document management with validity dates, automatic reminders before expiry and clear ownership on the supplier side. The onboarding path required is not fundamentally different from the commercial customer vetting we described in our article on B2B customer onboarding and business verification - it is simply documented more strictly. A B2B self-service portal is the natural place for both sides to see document status.

Accessibility as a de facto award criterion

This is where most suppliers drop out - not on price, but because the buyer cannot accept their ordering interface. The German Accessible Information Technology Ordinance (BITV 2.0) obliges public bodies to design their information technology in a comprehensively and fundamentally unrestricted accessible way (section 1, BITV 2.0). Its scope explicitly covers not only websites and mobile applications but also electronically supported administrative processes and graphical program interfaces (section 2, BITV 2.0).

A procurement portal that authority staff order from falls squarely into that category. Section 3 requires offerings to be perceivable, operable, understandable and robust; conformity is presumed when the harmonised standards published in the EU Official Journal are met (section 3, BITV 2.0). In addition, the public body has to provide an accessibility statement in an accessible and machine-readable format, update it annually and offer a feedback mechanism reachable from every page (section 7, BITV 2.0).

The ordinance addresses the public body, not the supplier. That is precisely why it becomes an award criterion: an authority that has to stand behind its own accessibility statement cannot deploy an ordering portal that is unusable without a mouse. The requirement therefore migrates from the ordinance into the specification - and an offer that cannot evidence it is typically not considered in the evaluation at all.

• Full keyboard operability with a visible focus indicator - from catalogue filters to submitting the order
• Correctly labelled form fields with programmatically associated labels, hints and error messages; the Leitweg-ID field is the practical test case here
• Sufficient contrast including status colours, prices and disabled controls
• Data tables with header cells - contract price lists and call-off overviews are unusable without table semantics
• Status messages for screen readers, for example when the cart updates or an approval is requested
• Documented test results, so accessibility can be evidenced in the offer rather than merely asserted

Entry checklist before your first framework contract bid

Before bidding for a framework contract, the shop should handle the following. The list is deliberately framed as a minimum - it describes what is actually asked for in practice, not the maximum build-out:

• Leitweg-ID as a dedicated mandatory field with check-digit validation, storable multiple times per account
• Purchase order number and cost centre as structured fields, not free-text comments
• Invoice output in XRechnung format to EN 16931, versionable and formally validated
• Transmission route to the buyer's receipt platform defined and tested
• Contract-capable pricing model with validity periods and a range cut per contract
• Catalogue delivery in a structured format including classification and versioning
• Punchout capability for at least one of the common standards
• Multi-user accounts with roles, value limits and approval chains
• Budget and remaining-value display per cost centre or contract
• Document management for credentials with expiry dates and reminders
• Accessible ordering interface with a documented test result
• Exportable call-off reporting per framework contract and public entity

A new customer segment, not a new feature

The commercial appeal of B2G lies not in an extra feature but in an extra market. The technical requirements - structured reference fields, contract prices, approval chains, accessible interfaces - pay in twice: they open access to public procurement and at the same time improve process quality for large commercial customers who buy in a similarly structured way.

XICTRON builds B2B shops from exactly these components: framework contract and call-off logic, approval and budget control, connections to procurement systems, and invoice output that holds up to public sector requirements. We build individually developed solutions rather than off-the-shelf packages, because contract structures differ considerably between industries and buyers. If you want to assess how far your shop is from being procurement-ready, let us talk about B2B e-commerce with procurement integration or about a specific project.

Frequently asked questions

Public sector buying is not an exotic side channel but a large, predictable B2B segment with clearly documented entry conditions. Suppliers that map those conditions into their shop stop competing on the daily price and start competing on process quality - and that is precisely where well-built B2B systems have the advantage.