Reviewers (PMD-3131):
User Story
As a Communication Service Provider, I want the system to generate invoices in EN 16931-compliant structured electronic formats (such as XML), so that I can meet EU e-invoicing requirements without manual intervention and allow business customers to import invoices directly into their ERP and accounting systems.
Example of use
A CSP issues monthly invoices to its clients. With EN 16931-compliant e-invoicing integrated into PortaSwitch, these invoices are automatically generated in a structured electronic format (e.g., XML) that is machine-readable and meets the European standard. This allows for seamless processing by clients' accounting systems and compliance with EU regulations.
Business model
Postpaid B2B, B2C
Technology
- Electronic Invoicing Standard: EN 16931
- Invoice Formats: Universal Business Language (UBL) and UN/CEFACT Cross Industry Invoice (CII)
Current Solution
PortaSwitch currently generates invoices in the PDF format. However, it lacks native support for exporting invoices in XML formats compliant with EN 16931, limiting interoperability with systems that require standardized electronic invoices.
Stakeholders and their benefits
| Benefit / Stakeholders | More Comfort | Increased Efficiency | Saves Time | Tighter Control | Replaces Human | Regulatory Requirement |
|---|---|---|---|---|---|---|
| CSP | ||||||
| Resellers / distributors | ||||||
| 3rd party | ||||||
| End user |
Use Cases
Use case #1: Generating EN 16931-Compliant Electronic Invoices
Roles: Admin/Reseller, PortaSwitch, (Sub)customer
Preconditions:
- A (sub)customer, "ABC Corp." is registered in PortaSwitch.
- "ABC Corp." has an active service agreement with a monthly billing.
- Previous invoices have been generated in PDF format.
- "ABC Corp." has outstanding due amounts from prior billing cycles.
Use scenario #1.1a: Regular electronic invoices for EN 16931 Compliance (happy path)
- The Admin/Reseller enables the option for EN 16931-compliant invoice generation on March 1, 2025, at 10:00 AM
- On April 1, 2025, PortaSwitch automatically generates the monthly invoice for "ABC Corp."
- The invoice includes all mandatory EN 16931 elements, such as invoice number, issue date, supplier and customer details, tax information, line items with descriptions, quantities, unit prices, and total amounts
- PortaSwitch sends the electronic invoice to "ABC Corp." via email (both PDF and XML, or XML only)
(Sub)customer imports the XML to their ERP for processing
- (Sub)customer arranges a payment according to the specified terms
- Some time later, (Sub)customer needs to access the XML again, so they download it (e.g. via the self-care portal)
Use scenario #1.1b: Regular electronic invoices for EN 16931 Compliance (failed XML, alternative to #1.1b)
- On April 1, 2025, PortaSwitch automatically generates the monthly invoice for "ABC Corp."
- XML generation fails (e.g. due to connectivity issue, invalid data structure etc.)
- Admin receives a notification about the failure with its reason
- Admin fixes the data for the invoice (and/or connectivity) and confirms it's ready for XML generation
- PortaSwitch sends the electronic invoice to "ABC Corp." via email (both PDF and XML, or XML only)
Use scenario #1.2: On-demand Out-of-turn electronic invoices for EN 16931 Compliance
- The Admin/Reseller identifies the need to issue an out-of-turn invoice for "ABC Corp." on March 15, 2025, at 2:00 PM, due to additional services rendered.
- The Admin/Reseller manually generates the EN 16931-compliant electronic invoice
- The system sends the invoice to "ABC Corp." via email (both PDF and XML, or XML only)
- "ABC Corp." imports the XML into their ERP system for processing
- "ABC Corp." arranges payment according to the specified terms
Use scenario #1.3: Voiding electronic invoices
- On April 5, 2025, at 11:00 AM, the Admin/Reseller identifies an error in the invoice sent to "ABC Corp."
- The Admin/Reseller selects the incorrect invoice and chooses to void it
- PortaSwitch marks the invoice as voided, visible in the PDF file
- A new, corrected EN 16931-compliant electronic invoice is automatically generated and sent to "ABC Corp." via email (both PDF and XML, or XML only)
- The (sub)customer imports the corrected XML into their ERP for processing
- The (sub)customer adjusts their accounting records correspondingly
Use scenario #1.4: Invoices requiring review
- On April 1, 2025, PortaSwitch automatically generates the monthly invoice for "ABC Corp." which requires review by Admin (no XML is generated before review)
- During review, Admin finds an error, corrects data in PortaBilling (re-rating, manual balance adjustments, etc) and re-issues the invoice (no XML is generated before review)
- Admin reviews the issued invoice and approves it
- XML is generated after the approval
- PortaSwitch sends the electronic invoice to "ABC Corp." via email (both PDF and XML, or XML only)
(Sub)customer imports the XML to their ERP for processing
- (Sub)customer arranges a payment according to the specified terms
- Some time later, (Sub)customer needs to access the XML again, so they download it (e.g. via the self-care portal)
Use scenario #1.5: PDF regeneration
- Admin decides to regenerate a PDF (e.g. after changing the invoice template)
- PortaSwitch does not retrigger the new XML generation as the invoice data remains unchanged
Use scenario #1.6: Re-issuing invoices under review
On April 1, 2025, PortaSwitch automatically generates the monthly invoice for "ABC Corp." which requires review by AdminAdmin decides to re-issue the invoice under review and then approves itXML is generated after the approvalPortaSwitch sends the electronic invoice to "ABC Corp." via email (both PDF and XML, or XML only)(Sub)customer imports the XML to their ERP for processing(Sub)customer arranges a payment according to the specified termsSome time later, (Sub)customer needs to access the XML again, so they download it (e.g. via the self-care portal)
Use scenario #1.6: Adjusting invoices
- Admin cannot adjust the invoice for which an XML was already generated - a new invoice/XML must be generated instead
Non-functional requirements
- PortaOne prefers to integrate PortaBilling with already compliant solutions, e.g. https://www.storecove.com
Peculiarities
- Example of the Storecove JSON payload for an invoice generated in EU/EEA for a German customer (single line item):
- Example of the Storecove JSON payload for an invoice generated in EU/EEA for a Dutch customer (multiple line items):
- No XML is required when invoice simulation is used
EN 16931 itself does not define storage or retention rules assuming that current logic with KeepInvoicesDays which is 0 by default (0 means - do not cleanup at all) should work
- For scenario 1.1b where Admin should receive a notification about failed invoice generation, according to https://docs.portaone.com/docs/mr127-available-notification-messages it seems that we do not have such notifications even for .pdf generation. If this is indeed the case, it makes sense to add such a notification (for both - .pdf, .xml or .pdf+.xml)
There is a number of invoice related options on PC WI so they will need to be revised during Solution Design phase and adjusted accordingly if needed (to support e-invoicing)
Performance / Clustering, Geo Redundancy/ Dual-Version, Porter / Call Control API
- Consider GDPR requirements for anonymizing personal data in e-invoice (.xml file)
- According to EN 16931, even if you anonymize PDF, the XML invoice must contain full legal data i.e. anonymization or altering XML is not allowed
- E-invoicing (XML) must be supported for the standalone mode and dual-version setup.
ESPF
No specific requirements for existing invoice related webhooks
Monitoring
Exact approach depends on the final design however, main point is that PortaOne support needs to understand whether e-invoice (.xml file) generation failed. For example: right now, if a .pdf file generation failed, support will see a monitoring alert for customer_statistics task

