Playbook4 min read

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 deliverableAccountable ownerEvidence to retain
Entity identity and tax treatmentFinance leadApproved legal-data and tax mapping
Credentials and source integrationIntegration leadCompany/scopes check and field mapping
Invoice and settlement correctnessControllerExpected versus actual financial examples
Send, receive and exception handlingOperations leadDelivery evidence and resolved exception
Release scope and residual riskSponsorDated 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

  1. Verify the active company before editing settings or creating an API key. For an integration, call GET /api/v1/me and compare the returned company and capabilities with the flow register.
  2. Confirm company identity, approved Peppol registration, customer addresses and participant reachability. Record which entity owns each sender and receiver identity.
  3. 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.
  4. 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.
  5. Prove reception with an agreed supplier. Open the inbound document, identify its legal recipient and assign its booking reference.
  6. Retrieve the actual exchanged XML and PDF where available. Prove that someone outside the integration team can locate them from an invoice number.
  7. 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.

Sources and references