Peppol e-invoicing from a self-hosted ERP

The ERP invoice register is the primary record, and the access point's transmission log confirms what left your systems and what arrived at the buyer's. Auditors usually ask for a complete list for a date range, with the status of each document. Reconcile the two sources by invoice number, Peppol message identifier and date. Confirm with your team:

• Which system is the book of record for outbound and inbound invoices.
• Whether the ERP stores the outbound UBL XML and the inbound file exactly as received.
• How rejected, errored and resent documents appear in the export.
• Whether the list can be filtered by counterparty and period without manual edits.

The access point's transmission responses and status messages are the main delivery evidence, stored alongside the invoice they relate to. A message showing the document was delivered to the receiving access point is stronger than an internal log saying the send button was clicked. Store these responses in the archive with the invoice record, not only in the connector's dashboard. Confirm with your access point provider or service provider how long they keep receipts, how you export them in bulk, and what a rejected or pending status looks like in their records. Confirm also how your team handles a missing response within the timeframe your internal procedure sets.

Configuration changes should be traceable to an approved ticket, a named person and a before and after record. Auditors look for change records for the connector, certificates, endpoint settings and mapping rules, not only for the invoice data. Keep connector configuration in version control where possible, and link each merge or deployment to a ticket in your ticketing system. Confirm with your team who approves changes to Peppol identifiers, certificates and tax mappings, how emergency changes are recorded afterward, and whether the ERP's own audit trail captures changes to master data such as tax IDs and buyer Peppol IDs.

Access evidence comes from the ERP's user activity logs, the identity provider's sign-in records and the access point's administrative logs. Under the FTC Safeguards Rule at 16 CFR 314.4, covered financial institutions must log the activity of authorized users, so the same expectation is a sensible baseline for any company handling financial records. Confirm that multi-factor authentication covers every account that can read or send invoices, that administrator actions are logged separately, that logs are kept in a location the ERP administrators cannot edit, and that you can produce a per-user access report for a stated period.

Retrieval depends on the archive store, the file format kept and how the invoice is indexed. Auditors usually ask for the original structured XML, any rendered PDF and the related receipts, all tied to one invoice number. Test retrieval before an audit rather than during one. Confirm with your team which retention period applies in each country where you invoice, whether the archive is write-once or protected against deletion, how invoices are indexed for search, and whether a test restore has been run on a sample set. Also confirm who holds the decryption keys and who can approve a restore request.

Keep dated test reports, scope documents, remediation tickets and retest evidence for every system in the invoicing path, including the ERP, the connector, the access point and the archive. The FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to run annual penetration tests and vulnerability assessments at least every six months unless continuous monitoring is in place. Confirm which systems are in scope, who performed each test, when the last test occurred and whether findings on the invoicing path were closed with evidence. DeployOpen runs security testing for applications, APIs and infrastructure, and the results can be provided as evidence, but the independent assessment of your controls remains with your auditor.

No. DeployOpen plans, implements, hardens and documents self-hosted systems, and prepares the controls and evidence that a compliance assessment will review. Independent auditors and certification bodies issue audit reports, attestations and certifications. Under a fixed-scope engagement, the deliverables should list the evidence each control produces, where it is stored and who owns it, so your auditor can test it. Confirm with your auditor which evidence they will sample, which periods they cover and whether they need access to the access point's records or only to your exports. Ask any implementation partner to state this boundary in writing.

The main drivers are the ERP edition, the route you choose, the number of trading partners, the integration work and the testing effort. Odoo Enterprise and Odoo Community differ in what is included, so the edition decides how much of the Peppol path you build yourself. Connecting to an external access point is a different cost profile from running your own access point and SMP, because the latter adds accreditation, certificates and operations. Each partner you must exchange invoices with adds mapping, validation and test cycles. Ask for a quote that separates one-time work (design, integration, testing) from recurring items (hosting, upgrades, certificate renewal, monitoring, any per-document fees from a provider). DeployOpen does not publish prices; a quote follows from a written scope.

Testing time depends mainly on how many trading partners you need to test with and how ready each one is. A partner with a working Peppol setup and clean master data can be tested quickly, while a partner that must fix its own system or identifiers adds waiting time you do not control. Your own ERP readiness, including tax IDs, Peppol participant IDs and invoice mapping, also sets the pace. No fixed duration applies across engagements, so confirm the testing plan, the partner list and the exit criteria in writing before work starts. Ask your implementation partner to show how it tracks partner readiness and failed test documents.

You need to provide clean master data for your company and customers, including legal names, tax identifiers and the Peppol participant identifiers you plan to use. You also need access to the ERP environment, the decision owners who can approve mappings and go-live, and a list of test partners who are willing to exchange sample invoices. Your finance and tax team should confirm which document types and tax treatments must be supported, and your security team should confirm how credentials and certificates will be stored. Missing inputs usually cause the most delay, so agree on an owner for each item during scoping.

A team with strong ERP administration and integration skills can handle parts of the work, such as master data cleanup and configuration, but Peppol adds network, certificate and validation requirements that most ERP teams have not run before. Connecting to an external access point usually leaves less infrastructure to run, while a self-hosted access point needs accreditation and ongoing operations. Decide which parts you will own, which parts a partner will deliver and how knowledge will transfer. A fixed-scope engagement can cover a defined part of the work with written deliverables, while ongoing support is available as a retainer. Confirm your team's gaps against the scope before deciding.

Recurring work includes ERP upgrades, certificate renewal, monitoring of transmissions and validation errors, and updates when mandates or formats change. On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years according to Odoo's upgrade documentation, so your Peppol integration must be retested after each one. Odoo standard support covers the first three years after a major release, and paid extended support is limited, so plan the upgrade path early. ERPNext releases minor versions frequently, so a patch cadence and regression tests are needed. Ask any partner for its upgrade, monitoring and support terms in writing, and confirm who owns certificate renewal and on-call response.

Yes, the edition affects what you can run and how you maintain it. Odoo Community is open source under LGPL-3.0, while Odoo Enterprise adds features, support and an upgrade service that requires an Enterprise subscription for on-premise use. Per Odoo's pricing page, only the Custom plan can be hosted on Odoo.sh or on-premise and includes external API access and custom modules, which matter for integration with an external access point. Confirm which Peppol capabilities your chosen edition and plan provide before you scope the work, because the answer changes both the build and the recurring cost.

Ask for a written scope with named deliverables, a partner list, test cases for each document type and clear acceptance criteria before go-live. Track progress by counting partners that have completed test exchanges, documents that passed validation and open defects by severity. Your team should also review how transmission errors are logged and who receives alerts. DeployOpen plans, implements, integrates, documents and supports self-hosted platforms in your own infrastructure, and it prepares systems and evidence for compliance assessments without issuing audit reports. Confirm that the reporting you receive matches the decisions you must make.