WHY TRUST THIS GUIDE 

Ingold Solutions is a Berlin-based SAP Silver Partner and Microsoft Solutions Partner, ISO 9001 certified, and a member of the Indo-German Chamber of Commerce, delivering SAP Business One implementations and integrations across 11 industry verticals from dual Germany and India delivery centres. This guide is written and maintained by our SAP Business One consulting team and reflects SAP's current FP 2602 documentation together with the regulatory status in Germany, Poland and the EU as of the time of writing. 

What Is E-Invoicing? 

E-invoicing means issuing and receiving invoices as structured, machine-readable data — typically XML — rather than as a PDF, a scanned image or a paper document. The key distinction that trips up a lot of finance teams the first time they encounter a mandate is that a PDF invoice, however professionally formatted, is not an e-invoice under most current legal definitions. An e-invoice needs to be structured in a way that lets the receiving system read, validate and process it automatically, without a person re-keying data from a visual layout.  That structured data typically follows the European standard EN 16931, with country-specific implementations — Germany's XRechnung, Poland's FA(3) schema used within KSeF, or the various Peppol BIS formats used across the wider Peppol network. A hybrid format like ZUGFeRD, which embeds structured XML inside a human-readable PDF, is designed to satisfy both a person opening the file and a system parsing it. 

Why E-Invoicing Is Becoming an ERP Issue 

E-invoicing used to sit mostly in the realm of accounts payable and tax compliance — a finance process, handled with a portal login or a bolt-on tool. That's changing quickly, because the source data an e-invoice needs — the customer's legal entity details, VAT identifiers, line-item tax codes, currency and payment terms — already lives in the ERP as part of every sales and purchasing document.  As Germany, Poland and a growing list of other countries move from optional to mandatory structured invoicing, the practical question for most mid-sized businesses stops being “should we adopt e-invoicing” and becomes “how does our ERP generate, validate and submit these documents without becoming a manual bottleneck.” For SAP Business One customers, that puts e-invoicing squarely inside ERP project scope rather than being treated as a separate finance-team initiative bolted on afterwards. 

How SAP Business One Handles Electronic Documents 

SAP Business One manages electronic documents through what SAP calls the eDocument framework, which converts a sales or purchasing document created in SAP Business One into the structured format a given country or network requires, then routes it through the appropriate channel for submission, validation and delivery confirmation.  Under SAP's current 10.0 FP 2602 documentation, the Web Client can generate electronic documents using both a generic eDocument protocol and the Peppol protocol, which extends structured document creation beyond the classic SAP Business One client into the browser-based Web Client that a growing share of day-to-day users now work from. This matters practically: it means e-invoicing capability isn't locked to a single desktop client, which is relevant for hybrid teams and remote finance staff working through the browser. 

SAP Business One and Peppol 

Peppol — Pan-European Public Procurement Online — is a network and message-exchange standard originally built for public-sector procurement across Europe, which has since expanded well beyond government contracts and beyond Europe itself; the network now spans roughly 30-plus European countries alongside Australia, New Zealand, Singapore, Japan, Canada and participants in the US.  Peppol works on what's usually described as a four-corner model: the sender's ERP (corner 1) hands the document to the sender's access point (corner 2), which routes it across the network to the recipient's access point (corner 3), which delivers it into the recipient's system (corner 4). The practical benefit for a business is the “connect once, connect to all” principle — one access point connection gives access to every other participant already on the network, rather than a separate integration per trading partner.  SAP Business One integrates with Peppol through SAP Document and Reporting Compliance, cloud edition, using the Electronic Document Service (EDS) to handle communication and processing, with a web-based dashboard for monitoring document status. Setting this up involves configuring connectors in EDS and setting up communication through SAP Business One's integration framework, and Peppol-specific functionality is available within certain country localisations rather than uniformly across every SAP Business One market. 

E-Invoicing in the SAP Business One Web Client 

The Web Client's growing role in FP 2602 is one of the more practically significant changes for finance teams. Generating electronic documents — through the generic eDoc protocol or through Peppol — directly in the Web Client means invoice creation, document generation and submission tracking no longer require switching to the classic client for this specific task.  For businesses running distributed or hybrid finance operations — a common pattern in the SMB and mid-market space Ingold typically works with — that browser-based capability reduces friction considerably: a finance user working remotely, or an SAP Business One HANA Cloud customer accessing the system entirely through the Web Client, can generate and submit compliant electronic documents without needing a locally installed client at all. 

Invoice Creation-to-Submission Workflow 

At a high level, the flow from a completed sales document to a submitted electronic invoice runs through several distinct stages, and it's worth understanding each one, because most implementation problems trace back to a gap at one specific stage rather than a failure of the framework as a whole. 

• Document creation — an A/R invoice or equivalent sales document is completed in SAP Business One as normal 

• eDocument generation — the system converts that document into the structured format required (XRechnung, FA(3), a Peppol BIS format, or another local schema) 

• Validation — the generated document is checked against the relevant schema and business rules before submission 

• Submission — the validated document is sent through the appropriate channel: Peppol access point, a national platform such as KSeF, or direct exchange with the recipient 

• Status tracking — the eDocument Cockpit or equivalent monitoring tool reflects acceptance, rejection or delivery confirmation back into SAP Business One 

• Archiving — the structured document is retained for the legally required retention period, which runs to eight years or more in several jurisdictions 

Each of those stages can fail independently — a document can generate correctly but fail schema validation, or validate correctly but fail to reach the recipient's access point — which is why status visibility at every stage, not just “sent” or “not sent”, matters for a finance team relying on this process daily. 

Incoming vs Outgoing E-Invoices 

It's worth treating incoming and outgoing e-invoices as genuinely separate processes, because the obligations, timing and system behaviour differ meaningfully between the two, and several current mandates — Germany's among them — require the ability to receive structured invoices well before they require issuing them. 

Outgoing e-invoices 

SAP Business One generates the structured document from a sales document, validates it against the applicable schema, and submits it through the relevant channel — this is the flow described above, and it's the process a business needs in place before any issuance mandate takes effect for them. 

Incoming e-invoices 

A structured invoice arriving from a supplier needs to be received, validated, and matched against the corresponding purchasing document, ideally with minimal manual re-entry. This is where a genuinely useful e-invoicing setup starts paying for itself in accounts payable efficiency, not just compliance — a well-configured incoming flow can auto-populate purchasing documents rather than leaving a finance team to key in data from a structured file by hand, which somewhat defeats the purpose of the format. 

Germany 

Germany's B2B e-invoicing mandate stems from the Wachstumschancengesetz (Growth Opportunities Act), passed by the Bundesrat in March 2024, and it is rolling out in clearly staged phases rather than as a single cut-over date. 

Date	Requirement
From 1 January 2025	All domestic businesses must be able to receive structured e-invoices for domestic B2B transactions — no turnover threshold applies to this obligation
Through 31 December 2026	Suppliers may still issue paper invoices or other electronic formats (such as plain PDF) with the recipient's consent
From 1 January 2027	Businesses with prior-year turnover above €800,000 must issue structured e-invoices for domestic B2B transactions
From 1 January 2028	The issuance obligation extends to all businesses, regardless of turnover

Accepted formats are those compliant with EN 16931, principally XRechnung and ZUGFeRD (2.0.1 and above, excluding certain minimal profiles), along with Peppol BIS 3.0. Germany has deliberately chosen a decentralised model — there is no central government clearance platform for B2B invoices, and documents are exchanged directly between trading parties via email, Peppol, EDI or API, which is a meaningfully different architecture from the centralised clearance models used in Poland or Italy.  For SAP Business One customers above the €800,000 threshold, 2027 is the date that matters most, but the receiving obligation is already live — which means the eDocument and Peppol capability in FP 2602 is relevant to German operations today, not only from 2027 onward.

Poland 

Poland's approach differs from Germany's in an important structural way: KSeF (Krajowy System e-Faktur) is a centralised clearance platform operated by the Polish tax authority, meaning invoices are validated and issued through the government system itself, not exchanged directly between trading parties. 

Date	Requirement
1 February 2026	Mandatory for large taxpayers, defined as businesses with turnover above PLN 200 million (roughly €46 million) in the prior year
1 April 2026	Mandatory for all other VAT-registered businesses in Poland
1 January 2027	Mandatory for micro-entrepreneurs, and cash-register receipts carrying a buyer NIP can no longer be issued outside KSeF

 As of the time of writing, both the large-taxpayer and general-business phases of the Polish mandate are already in force. Invoices are submitted in the FA(3) XML schema, validated by KSeF, and assigned a unique KSeF ID before they're considered officially issued — an invoice sent outside this process, once the mandate applies to a given business, isn't legally an issued invoice at all, regardless of what the document itself looks like. The Ministry of Finance has confirmed no penalties apply through the end of the 2026 calendar year, giving businesses a practical grace period to resolve technical issues, though this shouldn't be read as an extension of the underlying deadlines themselves.  For SAP Business One customers with Polish operations, this makes KSeF integration a live operational requirement rather than a future planning item. 

EU Cross-Border Transactions 

Domestic mandates such as Germany's and Poland's currently apply to domestic B2B transactions within each country — cross-border intra-EU transactions sit outside both mandates for now. That's set to change under the EU's VAT in the Digital Age (ViDA) package, which introduces mandatory digital reporting and structured e-invoicing for cross-border B2B transactions across the EU from 1 July 2030.  This is worth framing accurately rather than urgently: 2030 is a genuine date on the regulatory calendar, not an immediate compliance requirement. But the architectural groundwork — structured invoice data, consistent VAT identifiers across systems, auditable electronic document flows — tends to take longer to build properly than businesses expect, which is why it's reasonable to treat domestic mandates like Germany's and Poland's as a practical opportunity to get that groundwork right well ahead of the EU-wide cross-border deadline, rather than solving each country's requirement in isolation and then facing another rebuild for ViDA. 

Integrating Third-Party E-Invoicing Platforms 

Not every business runs e-invoicing purely through SAP's native eDocument and Peppol capability. Some operate through a specialised third-party e-invoicing or tax-compliance platform — often because they already use that provider across other ERPs or subsidiaries, or because a particular country's requirements are better served by a specialist tool at this stage in its rollout.  Where that's the case, the integration question becomes how cleanly SAP Business One's document data feeds into the third-party platform, and how status updates — accepted, rejected, delivered — flow back into SAP Business One so accounts payable and receivable teams aren't checking two separate systems to know whether an invoice actually went through. A well-scoped integration keeps SAP Business One as the operational system of record while letting the specialist platform handle country-specific validation and submission logic that changes faster than most businesses want to be reconfiguring their ERP directly. 

Common Implementation Problems 

Treating e-invoicing as a finance-only project 

E-invoicing touches master data quality, document numbering, tax code configuration and ERP customisation, not just the accounts payable and receivable teams — leaving IT and ERP consultants out of the project scope is one of the more common causes of delay. 

Underestimating master data cleanup 

Structured e-invoices are far less forgiving of incomplete or inconsistent customer and vendor master data — missing VAT identifiers or inconsistent legal entity names, which a human eye might tolerate on a PDF, will fail schema validation outright. 

Assuming one country's setup covers another 

Germany's decentralised, direct-exchange model and Poland's centralised clearance model are architecturally different — a business operating in both countries needs distinct configuration for each, not a single generic “e-invoicing module” switched on once. 

No monitoring for rejected or stuck documents 

Without visibility into the eDocument Cockpit or equivalent status tracking, rejected invoices can sit unresolved, which risks both cash flow (unpaid invoices) and compliance (invoices that were never actually issued). 

Leaving format changes for later 

Schemas evolve — Poland's FA(3) replaced FA(2), and Germany's accepted ZUGFeRD versions have specific minimum requirements — and a static implementation that isn't built to accommodate schema updates tends to need rework sooner than expected. 

Underestimating archiving requirements 

Several jurisdictions require structured invoices to be retained in their original format for eight years or more; treating archiving as an afterthought rather than part of the initial implementation creates audit risk later. 

SAP Business One E-Invoicing Implementation Checklist 

☐  Confirm which country mandates currently apply to your operations, and their exact effective dates  ☐  Audit customer and vendor master data for completeness — VAT IDs, legal entity names, addresses  ☐  Determine which formats are required (XRechnung, ZUGFeRD, FA(3), Peppol BIS, or others)  ☐  Decide between SAP's native eDocument/Peppol capability and a third-party platform, or a combination  ☐  Configure the Web Client or classic client eDocument generation for your document types  ☐  Set up Peppol access point connectivity where relevant, via SAP Document and Reporting Compliance, cloud edition  ☐  Build a monitoring process for document status — generated, validated, submitted, accepted, rejected  ☐  Define the incoming invoice matching process against purchasing documents  ☐  Confirm archiving configuration meets the retention period required in each relevant jurisdiction  ☐  Plan for schema updates as an ongoing maintenance item, not a one-off setup task  ☐  Involve both finance and IT/ERP consulting stakeholders from project kickoff 

How Ingold Solutions Supports SAP Business One E-Invoicing 

As a Berlin-based SAP Silver Partner delivering SAP Business One implementations, integrations and ongoing support across Germany, the wider EU and international markets, Ingold Solutions works with clients on exactly this kind of compliance-driven ERP configuration — mapping which mandates actually apply to a given business, configuring eDocument and Peppol capability inside SAP Business One, cleaning up the master data structured invoicing depends on, and setting up the monitoring and archiving processes that keep an e-invoicing implementation reliable well after go-live rather than just on day one.  Whether you're preparing for Germany's 2027 issuance deadline, already operating under Poland's KSeF mandate, or mapping out a multi-country e-invoicing strategy ahead of the EU's 2030 cross-border requirements, getting the underlying SAP Business One configuration right early tends to be considerably less disruptive than retrofitting it against a live deadline.  Get in touch with Ingold Solutions to discuss your SAP Business One e-invoicing requirements and how our team can support your implementation across Germany, the EU and beyond.