Enterprise rollout: from discovery to operational handover
A staged implementation playbook for legal entities, financial controls, Peppol, integrations and a measurable go-live decision.
- Updated
- Content owner
- Implementation team
- For
- Implementation leads · Finance directors · Service delivery teams
At a glance
Release one verified entity and workflow at a time, with named owners, representative evidence and a controlled exception queue.
Before you begin
- A named business sponsor and operational owner
- An inventory of legal entities, invoicing flows and source systems
- Access to the company configuration and agreed test counterparties
What you will achieve
- A documented scope and readiness decision
- Evidence for issuance, reception, settlement and retrieval
- An operating team able to resolve exceptions after handover
On this page
An enterprise implementation succeeds when a finance team can issue, receive, reconcile and retrieve its documents without depending on the project team. Registration and a successful first invoice are milestones; they do not demonstrate that every entity, tax treatment or recovery path is ready.
Use this playbook for a new service deployment or a material expansion. The ownership and gates below are recommended operating practices. Record approvals in your existing project or service system; they are not an OrdoGrid approval workflow.
Agree scope before configuration
Create a flow register with one row per legal entity and document flow. Record the supplier identity, customer population, invoice and credit-note source, expected volume, currency, payment source, delivery channel, archive owner and current access point. Separate Belgium outbound Peppol from other requirements: the current product's outbound supplier support remains Belgian companies. An entity outside that scope needs an explicit solution decision before release.
Choose an initial slice that is small enough to reconcile completely and representative enough to expose risk. A low-volume entity using one currency is useful, provided it includes real examples of deposits, credit notes and buyer references where those occur. Label unsupported requirements as open decisions, never as completed configuration.
Assign decisions and evidence
| Decision or deliverable | Accountable owner | Evidence to retain |
|---|---|---|
| Entity identity and tax treatment | Finance lead | Approved legal-data and tax mapping |
| Credentials and source integration | Integration lead | Company/scopes check and field mapping |
| Invoice and settlement correctness | Controller | Expected versus actual financial examples |
| Send, receive and exception handling | Operations lead | Delivery evidence and resolved exception |
| Release scope and residual risk | Sponsor | Dated go-live decision and exclusions |
Give each role a named deputy. Define how the team reaches support and the access-point provider using your actual service agreement. An internal response target is a team commitment; this guide does not establish a provider SLA.
Build a representative acceptance pack
- Verify the active company before editing settings or creating an API key. For an integration, call
GET /api/v1/meand compare the returned company and capabilities with the flow register. - Confirm company identity, approved Peppol registration, customer addresses and participant reachability. Record which entity owns each sender and receiver identity.
- Produce a standard invoice and a credit note linked to its original. Compare lines, discounts, tax breakdowns, currency, payable amount and reference data with controller-approved expectations.
- Exercise a partial payment and a refund scenario. Check settlement totals; a credit note changes commercial debt, whereas a refund records cash already returned outside OrdoGrid.
- Prove reception with an agreed supplier. Open the inbound document, identify its legal recipient and assign its booking reference.
- Retrieve the actual exchanged XML and PDF where available. Prove that someone outside the integration team can locate them from an invoice number.
- Run one recovery case: lost create response, invalid address or unreachable participant. Demonstrate diagnosis and safe recovery without a second numbered invoice.
OpenPeppol publishes separate invoice and credit-note syntax and validation rules in BIS Billing 3.0. A readable PDF alone does not prove that the exchanged structured document passed the intended workflow.
Make the release decision explicit
For every acceptance case, retain the source reference, expected result, product document ID, actual result, timestamps and evidence location. Record the tester and the person accepting the financial result. Keep secrets and unnecessary personal data out of screenshots and project tickets.
Release requires no unexplained financial difference, no unidentified legal recipient and no unresolved duplicate-risk transmission. A cosmetic defect can be accepted with an owner and date. An uncertain send must be reconciled before it is retried. Do not use a new invoice number to hide a failed test or an unresolved source transaction.
Example: a two-entity service group
A group starts with its Belgian consulting entity: 80 monthly invoices, EUR, deposits on larger contracts and a separate logistics subsidiary. The pilot includes a €121 invoice with €40 paid, leaving €81 outstanding. A €60.50 credit against a fully paid €121 invoice creates €60.50 refund due; recording the actual refund clears that amount.
The consulting entity releases first because its send, receive and archive tests pass. Logistics remains excluded because its supplier-recipient mapping is incomplete. The project reports a successful limited release, not a group-wide rollout.
Hand over a service, then expand
Give operations the entity register, source mapping, credential owner, reconciliation schedule, exception queue, evidence pack and change calendar. Walk a deputy through an incident without prompting. Set an observation period based on actual billing cycles and volumes, then compare source counts, settlement differences and unresolved exceptions.
Expand only after the first slice can operate independently. Use billing controls for daily assurance and incident response when a release exposes a material problem.