Getting Started with eInvoicing

Forms of eInvoicing

eInvoicing comes in various forms, each with its own characteristics and application areas. Important to know: a PDF invoice sent by email is not an einvoice in the technical sense. A true einvoice is a structured data file (usually XML) that can be processed automatically without human intervention.

Open Networks: Peppol (Europe) & DBNA (US)

Peppol (Pan-European Public Procurement On-Line)

Peppol is the dominant open network for einvoicing in Europe and beyond. Originally developed for European public procurement, it has grown into a global standard for B2B and B2G invoicing, active in more than 40 countries including Australia, Singapore, and Japan. The network operates on the 'four-corner model' where each participant communicates through a certified Access Point.

Core Features of Peppol:

• Standardized document formats: Primarily UBL 2.1 (Universal Business Language) with Peppol BIS (Business Interoperability Specifications)
• Unique identification: Each organization has a unique Peppol ID (usually based on Chamber of Commerce number in the Netherlands)
• Service Metadata Publisher (SMP): Central directory that tracks which documents an organization can receive
• AS4 protocol: Secure transport layer for message exchange between Access Points
• End-to-end encryption: Messages are sent encrypted between Access Points

Implementation of Peppol:

To connect to Peppol, you need a certified Access Point. In the Netherlands, there are more than 30 certified Access Point providers, ranging from pure technical providers to full-service providers with complete invoicing solutions. Implementation typically proceeds as follows:

1. Access Point provider selection: Choose a provider that fits your organization (price, functionality, support)
2. Registration in SMP: Your organization is registered with a unique Peppol ID
3. Technical connection: Integration with your accounting software or ERP system
4. Validation and testing: Exchange test messages to verify correct operation
5. Go-live: Start production exchange of invoices

DBNA (Digital Business Network Alliance)

DBNA is the American counterpart to Peppol, founded in response to the growing need for standardized einvoicing in North America. Like Peppol, DBNA strives for an open, interoperable network for B2B and B2G electronic documents, but specifically tailored to the American market.

Specific features of DBNA:

• American focus: Designed for US Tax compliance and American business practices
• Interoperability with Peppol: Working on cross-network connectivity between US and Europe
• Multi-format support: Supports both UBL and ANSI X12 standards
• Federal and State compliance: Meets various government requirements at federal and state levels
• Growing adoption: More and more US states are mandating einvoicing for government contracts

Other regional networks:

Besides Peppol (Europe/Asia-Pacific) and DBNA (US), similar initiatives are emerging worldwide:

• Latin America: Various countries are working on national einvoicing networks, often based on local tax requirements
• India: GST Network for VAT compliance with einvoicing mandate
• China: Fapiao system for tax control

The trend is that these networks seek interconnectivity, with Peppol often being adopted as the technical standard.

Billing Service Providers (BSP) with Private Networks

Billing Service Providers are commercial parties that operate their own, often closed networks for einvoicing. These providers typically offer end-to-end solutions where they manage the complete invoicing chain, from creation to archiving.

Characteristics of BSP Networks

BSP networks differ fundamentally from open networks like Peppol. Where Peppol uses a standardized protocol that guarantees interoperability, BSPs often use proprietary formats and protocols. This has advantages and disadvantages:

Advantages of BSP networks:

• All-in-one solutions: Complete invoicing suites including portals, workflow management, and archiving
• Ease of use: Often very user-friendly interfaces with no technical knowledge required
• Value-added services: Additional services like invoice financing, collection, credit management
• Legacy format support: Can often also process PDF and other unstructured formats
• Quick implementation: Plug-and-play solutions without complex integrations

Disadvantages of BSP networks:

• Vendor lock-in: Difficult to switch to another provider
• Limited reach: Only organizations within the same network can communicate directly
• Higher costs: Often more expensive than open networks due to proprietary technology
• Roaming fees: Extra costs for communication with other networks
• Dependency: Completely dependent on the continuity and stability of the provider

Well-known BSPs in the Netherlands

The Dutch market has several large BSPs, each with their own specializations:

• Basware: Focus on large enterprises, strong P2P automation
• Tungsten Network: Worldwide network, specializing in supply chain finance
• Tradeshift: Platform approach with marketplace functionality
• InvoiceSharing: Dutch player, strong in SME segment
• Storecove: API-first approach, suitable for SaaS integrations

Many BSPs now offer hybrid models where they facilitate both their own network and access to open networks like Peppol. This gives organizations the best of both worlds.

EDI (Electronic Data Interchange)

EDI is the oldest form of electronic data exchange between companies, in use since the 1970s. Although older than modern einvoicing standards, EDI remains dominant in certain sectors due to deep integration in existing supply chains.

EDI Standards and Formats

EDI has various standards used worldwide or regionally:

EDIFACT (UN/EDIFACT)

The international standard developed by the United Nations, particularly popular in Europe. EDIFACT messages such as INVOIC (invoice), ORDERS (purchase order), and DESADV (shipping advice) form complete trade chains. The syntax is compact but complex, requiring specialist knowledge.

ANSI X12

The American counterpart to EDIFACT, dominant in North America. Documents are designated with numbers: 810 (Invoice), 850 (Purchase Order), 856 (Ship Notice). Many multinationals must support both standards.

Industry-specific dialects

Many sectors have developed their own EDI dialects:

• Retail: GS1 EANCOM (subset of EDIFACT for retail and FMCG)
• Automotive: VDA (Germany), ODETTE (Europe), AIAG (US)
• Healthcare: HL7 for medical data, often combined with EDI for invoicing
• Transport: IATA Cargo-IMP for aviation, IFTMIN for shipping

EDI Implementation and Infrastructure

Value Added Networks (VANs)

Traditionally, EDI traffic flows through VANs - private networks that act as intermediaries. Well-known VANs include IBM Sterling, OpenText GXS, and Descartes. VANs offer:

• Store-and-forward messaging
• Protocol and format conversion
• Guaranteed delivery
• Trading partner management
• Compliance monitoring

AS2 and AS4 Connectivity

More and more organizations are choosing direct connections without VAN, where two protocols dominate:

AS2 (Applicability Statement 2) - The classic protocol for EDI since 2002:

• Point-to-point communication over HTTP/HTTPS
• Synchronous message exchange with direct confirmation
• MDN (Message Disposition Notification) for receipt confirmation
• Widely adopted in North America and automotive sector
• Relatively simple to implement

AS4 (Applicability Statement 4) - The modern successor since 2013:

• Based on Web Services (SOAP) with WS-Security
• Supports both synchronous and asynchronous communication
• Multi-hop routing possible (not just point-to-point)
• Used in Peppol for the four-corner model
• Better error handling and reliability features
• Can send multiple payloads in one message

EDI Mapping and Integration

The biggest challenge with EDI is 'mapping' data between internal systems and EDI formats. This requires:

• EDI translator software: Such as IBM Sterling B2B, Seeburger BIS, or open source alternatives
• Mapping expertise: Specialists who translate business processes into EDI structures
• Testing protocols: Extensive testing with each trading partner
• Maintenance: Continuous adjustments for changes in requirements

API Integration

API-based einvoicing represents the modern approach where real-time data exchange is central. Instead of batch-oriented processes like EDI, APIs enable direct, synchronous communication between systems.

REST APIs vs SOAP Web Services

REST APIs (Representational State Transfer)

The modern standard for web APIs, based on HTTP protocols:

• JSON payload: Lightweight data format, easy to parse
• Stateless: Each request contains all necessary information
• Resource-based: URLs represent resources (e.g., /invoices/12345)
• HTTP methods: GET (retrieve), POST (create), PUT (update), DELETE (remove)
• Webhooks: Event-driven notifications for status changes

Example of a REST API call for einvoicing:

SOAP Web Services

The older but still used protocol for enterprise integrations:

• XML-based: Extensive but verbose messaging
• WSDL contracts: Formal interface definitions
• WS-Security: Enterprise-grade security features
• Transactional support: ACID compliance for critical operations
• Error handling: Standardized SOAP faults

Benefits of API-driven eInvoicing

• Real-time processing: Immediate feedback on invoice status and validation
• Flexible integration: Easy to implement in modern architectures
• Event-driven workflows: Automatic actions for specific events
• Microservices compatible: Fits perfectly in modern IT landscapes
• Developer-friendly: Extensive documentation, SDKs, and sandbox environments
• Scalability: Cloud-native architecture for elastic capacity

Implementation of API eInvoicing

Authentication and Security

• OAuth 2.0: Industry standard for API authentication
• API Keys: Simple authentication for basic use cases
• JWT tokens: Stateless authentication with claims
• Rate limiting: Protection against overload
• IP whitelisting: Extra security layer for enterprise

Typical API providers in the Netherlands

• Storecove: API-first platform with extensive documentation
• Basware API: Enterprise-grade with SOAP and REST options
• Exact Online API: Integrated in accounting software
• Unit4 API: Focus on mid-market organizations
• Visma eAccounting API: Scandinavian provider with strong API

Hybrid Models and Future Perspective

In practice, many organizations choose hybrid solutions that combine different einvoicing methods. This offers maximum flexibility and reach.

Common Hybrid Configurations

Peppol + BSP Combination

Organizations use Peppol for government contracts and a BSP for commercial customers. This provides B2G compliance while the BSP delivers additional services for B2B such as:

• Dynamic discounts and payment terms
• Supply chain financing options
• Integrated credit management
• Multi-channel delivery (email, portal, API)

EDI + Modern eInvoicing

Large retailers and manufacturers maintain EDI for order-to-cash processes but adopt Peppol/UBL for invoicing. This provides:

• Preservation of investments in EDI infrastructure
• Modern invoicing compliance
• Gradual migration capabilities
• Best-of-breed for different processes

API Gateway Architecture

A central API gateway that translates between different protocols and formats:

• Inbound: Peppol, EDI, API calls, email
• Internal processing: Standardized format
• Outbound: Automatic selection of optimal channel per partner
• Single point of integration for internal systems

Comparison of eInvoicing Methods

Aspect	Peppol	BSP Networks	EDI	API Integration
Reach	Worldwide, open network	Limited to network members	Point-to-point connections	Depends on provider
Standardization	UBL 2.1, EN16931	Often proprietary	EDIFACT, X12, industry-specific	JSON/XML, provider-specific
Implementation	2-8 weeks	1-4 weeks	3-6 months	2-12 weeks
Costs	€50-500/month	€200-2000/month	€1000-10,000/month	€100-1000/month
Suitable for	All organizations, especially B2G	SMEs without IT resources	High-volume B2B	Tech-savvy organizations
Advantages	Open standard Wide reach Future-proof	All-in-one Ease of use Extra services	Complete chain Proven High volumes	Real-time Flexible Modern
Disadvantages	Technical knowledge required	Vendor lock-in, higher costs	Complex, expensive, slow	Provider dependent

Implementation Roadmap

Regardless of which form of einvoicing you choose, a structured approach is essential for successful implementation: