Peppol eInvoicing (EU)

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €34/mo; per-country obligation: Peppol format generation, SMP directory lookup

Generated from docs/plan/paid/peppol-einvoicing/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

A paid service for EU B2B merchants: auto-generates Peppol eInvoice XML (EU compliance standard for all B2B invoices), looks up business partner endpoints via the Peppol SMP directory, and optionally auto-sends to customer.

The problem

A German B2B merchant (B2C sales exempt) issues 200 invoices per month to other EU businesses. From Jan 2024, all EU B2B invoices must be in Peppol eInvoice format. She manually creates PDFs and emails them. Peppol format is complex XML—she’d need a developer (€2k) to implement it. Without it, customers (big corporations) reject invoices.

What it does

• Peppol eInvoice XML generation: UBL 2.1 format, all mandatory/conditional fields per spec
• Peppol Business Message Envelope (BME): wraps invoice in standard transport format
• SMP (Service Metadata Publisher) lookup: find customer’s Peppol endpoint from their organization number
• Endpoint resolution: auto-detect customer Peppol network (PEPPOL, Pagero, Tradeshift, etc.)
• Auto-send option: optionally send eInvoice directly to customer’s Peppol inbox
• Invoice PDF alternative: if customer doesn’t accept Peppol, fallback to PDF email
• Delivery status tracking: know if Peppol network accepted the invoice
• Invoice archive: all Peppol eInvoices stored locally (audit trail)
• Error handling: if SMP lookup fails or endpoint invalid, alert merchant, provide manual entry option
• Compliance validation: exported XML validates against Peppol XSD before sending

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Accepting Peppol invoices from customers (inbound)—separate feature
• Accounting system integration (posting received eInvoices to GL)—out of scope
• Subscription/recurring invoices—handled as separate invoices, each is separate eInvoice
• Digital signature on invoice (optional in Peppol; out of scope for now)
• Non-EU eInvoicing standards (UK, Switzerland)

Data model

Extend Invoice: peppol_invoice_xml, peppol_recipient_endpoint, peppol_delivery_status, peppol_sent_at. New: PeppolSMPLookup(organization_id, endpoint_uri, network_id, lookup_date, valid_until). No core migration; stored in plugin settings.

API

• POST /invoices/:id/generate-peppol — generate Peppol eInvoice XML
• POST /invoices/:id/send-peppol — send via Peppol network
• GET /invoices/:id/peppol-status — return delivery status
• POST /peppol/lookup/:organization_id — look up Peppol endpoint
• GET /peppol/archive — list all sent eInvoices
• POST /peppol/validate-xml — validate XML against Peppol XSD

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Peppol dashboard: invoice list with Peppol status (not sent/sent/delivered/failed), send button (batch send), SMP lookup tool, archive (all sent eInvoices with delivery status), error log (failed lookups, send failures)

The seam — why this is paid

Core owns: invoice data structure. Paid pack owns: Peppol XML schema implementation, SMP directory lookup API, Peppol network credentials (for auto-send), compliance validation.

Per-country obligation: EU Peppol mandate (2024+), we generate compliant invoices

Dependencies

• invoice system (core; invoices must exist before creating Peppol versions)
• email layer (fallback if Peppol fails)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• An invoice for a German business with organization number ‘DE123456789’ generates valid Peppol eInvoice XML (validatable against Peppol XSD)
• SMP lookup for ‘DE123456789’ returns Peppol endpoint URL
• Peppol eInvoice XML includes all mandatory fields: invoice number, date, supplier, customer, amounts, VAT
• Sending eInvoice via Peppol network returns delivery status ‘sent’ within 30 seconds
• If SMP lookup fails, merchant sees error and can manually enter endpoint URL
• Archive shows all sent eInvoices with timestamp, recipient, delivery status
• Validation: exporting XML and pasting into Peppol validator tool passes without errors
• If Peppol send fails, fallback sends PDF via email to customer (merchant can configure)

Risks

Peppol eInvoice format is complex; XML generation bug breaks all sent invoices. SMP lookup failures (network down, endpoint invalid) block invoice sending. If we auto-send without confirmation, merchant might inadvertently send invoices to wrong endpoint. Peppol network outages mean invoices don’t reach customers. Schema changes: Peppol spec evolves, old XML versions become invalid.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.