Global rollout runbook: Demo Global Ventures Group

This runbook is the common implementation spine for all OSERP industry scenarios. Demo Global Ventures Group is a fictional holding structure with a UAE trading company, an India services company, and a Saudi retail company. The group has 14 branches, eight warehouses, AED/INR/SAR/USD/EUR transactions, separate tax registrations, shared services, inter-company purchasing, and different approval thresholds. The purpose is to teach an implementer what to decide, what to configure, what evidence to collect, and what not to assume.

Phase 1 — Scope the legal and operating model

Start with a signed scope register. Do not begin by importing every spreadsheet. Record tenant, organisation, legal companies, branches, warehouses, books, countries, currencies, tax regimes, fiscal calendars, industries, integrations, users, and go-live waves.

Object	Example	Why it must be settled first
Tenant	dgv-group	Isolation boundary for all data
Organisation	Demo Global Ventures Group	Shared governance and membership
Company	DGV UAE Trading LLC	Legal books, tax, currency, reports
Branch	Dubai DC / Abu Dhabi Store	Local responsibility and access
Warehouse	WH-DXB, WH-AUH	Stock ownership and movement
Book	Leading IFRS, local tax	Parallel reporting basis
Country	UAE, India, Saudi Arabia	Tax, address, currency, compliance
Industry mode	Trading, services, retail	Relevant master and scenario choices

A branch is not a company, and a warehouse is not a branch. A branch can have several warehouses; an inter-company transfer is not an inter-branch transfer. Document this distinction before designing numbering, permissions, and reports.

Phase 2 — Company profile and numbering

For each company, complete legal name, registration number, tax identifiers, address, country, base currency, fiscal year, date format, language, time zone, rounding precision, and default book. Keep the group’s display name separate from the legal issuer printed on invoices.

Create numbering series by company, process, branch, and stage where policy requires it. A sales invoice number should be unique, chronological under the local policy, and traceable to the company. Do not use one shared series if the legal entities file separately. Do not reuse a number after cancellation unless local policy explicitly permits it.

The numbering catalogue is configuration, not decoration. Test invoice, credit note, payment, receipt, purchase invoice, transfer, adjustment, and journal numbering in every wave. Record who can change a series and how an emergency gap is explained.

Phase 3 — Currencies and exchange-rate policy

Set each company’s base currency. Add transaction currencies only when the business has a real need. Define rate source, effective date, quote direction, decimal precision, stale-rate tolerance, and who may override a rate. A USD invoice in an AED company stores original USD, the rate, and base AED amount; it does not replace AED books.

Run these tests before transactions:

1. Base-currency sales invoice with no conversion.
2. Foreign-currency invoice with current rate.
3. Missing rate refusal.
4. Stale rate warning or refusal according to policy.
5. Receipt at a different rate and realised FX difference.
6. Period-end revaluation in the approved book.

Never change an original invoice rate to make a later bank settlement equal. The difference is an accounting result that needs explanation.

Phase 4 — Tax and place of supply

For each company, list tax registration, tax period, domestic states/provinces, place-of-supply rule, standard/zero/exempt categories, import treatment, reverse charge, export evidence, and return/report ownership. Map item tax categories and business-partner registrations before opening sales or purchase posting.

The same product can produce different tax components by company, customer country, branch, and place of supply. Simulate domestic, inter-state, export, exempt, service, import, return, credit-note, and advance cases. A tax total that balances can still be classified incorrectly.

Use the GL Mapping test with realistic amounts. For an intra-state sale, expect the configured CGST/SGST roles; for an inter-state/export sale, expect the configured IGST or zero-rated roles. If both simulations resolve identically, stop the rollout and correct the rule priority or context.

Phase 5 — Chart of accounts and dimensions

Build account groups before ledgers. Agree naming, normal balance, posting status, currency, tax role, reconciliation flag, and reporting hierarchy. Then create dimensions: cost centre, profit centre, segment, project, programme, fund, and WBS. Dimensions answer “who owns this result?” while the ledger answers “what kind of result is it?”

The UAE trading company may need inventory, COGS, domestic revenue, export revenue, output tax, bank, AR, AP, freight, duty, and FX roles. The India services company may need unbilled work, deferred revenue, billable time, and consultant cost. Do not copy a trading chart into a services company without policy review.

Map semantic roles to real ledgers through GL Mapping. Keep template shape separate from account destination. Use specific conditions with lower priority than generic fallbacks, then run What-If and save a configuration version.

Phase 6 — Master data migration

Migrate in dependency order:

1. Countries, currencies, tax types, UOMs, payment modes, and numbering.
2. Companies, branches, warehouses, bins, books, periods, dimensions, and roles.
3. Items, categories, brands, barcodes, batches, price lists, and opening stock.
4. Customers, suppliers, addresses, contacts, tax registrations, terms, and credit profiles.
5. Employees, roles, permissions, projects, contracts, and budgets.
6. Opening balances, open receivables/payables, advances, stock, and bank balances.

Every import needs source file, row key, owner, import mode, validation result, rejected rows, rerun key, and reconciliation total. A blank value must be distinguished from zero, unknown, not applicable, and intentionally deleted. Never import a spreadsheet’s “customer name” into a legal partner field without deduplication and tax validation.

Phase 7 — Security and operating roles

Define least-privilege roles for tenant administrator, company administrator, accountant, sales user, purchasing user, warehouse user, cashier, approver, payroll user, project manager, auditor, integration service, and AI reader. Scope access by tenant, organisation, company, branch, warehouse, project, and sensitive field.

Test both menu access and operation access. A user may see a sales screen but be unable to post an invoice; a warehouse user may receive goods but not alter a supplier tax registration; an approver may approve but not edit the source document. Record every negative test as carefully as every successful test.

Phase 8 — End-to-end rehearsal

Use one scenario per industry and one global scenario. For each, record source data, screen, field, owner, permission, stage, expected stock, expected journal, tax, currency, report, and evidence. Required rehearsals include:

• Retail: purchase → receipt → transfer → POS sale → return → settlement.
• Trading: import → landed cost → quarantine → branch allocation → sale.
• Manufacturing: BOM → work order → issue → inspection → finished receipt.
• Consulting: project → time → expense → milestone → invoice → revenue.
• Hospitality: reservation → deposit → folio → outlet POS → night close.
• E-commerce: checkout → gateway → reservation → split shipment → refund.
• Projects: contract → budget → commitment → progress → retention.
• Education: enrolment → scholarship → instalment → attendance → completion.
• Nonprofit: grant → restricted budget → procurement → distribution → donor report.

For every rehearsal, execute a deliberate failure: closed period, missing FX rate, insufficient stock, duplicate reference, missing stage field, wrong tax registration, rejected approval, duplicate webhook, and unauthorised role. A green-path-only rehearsal is not readiness evidence.

Phase 9 — Cutover and opening balances

Freeze master changes, reconcile source systems, export final open items, approve opening balances, and record cutover timestamp. Load open AR/AP with original document date, due date, currency, rate, remaining amount, customer/supplier, and source reference. Load stock by item, warehouse, bin, batch/serial, quantity, cost, and evidence. Do not load a single net balance if users need to allocate future payments to individual invoices.

The cutover report must reconcile trial balance, AR, AP, inventory, bank, tax, advances, deferred revenue, retained earnings, and dimensions to the approved source totals. Keep the source extract immutable and record every transformation.

Phase 10 — Hypercare and continuous learning

For the first close, run daily exception review: missing journals, unmapped roles, unallocated receipts, negative stock, overdue approvals, stale FX, failed webhooks, tax mismatches, open returns, and period errors. Every incident gets severity, owner, reproduction steps, source document, correction, prevention, and Academy article link.

The Academy should grow from these real questions. A new field is not documented by its label alone: add purpose, example, type, limit, default, dependency, permission, validation, downstream impact, report impact, API representation, and negative case. Mark whether the behavior is product-supported, configured, policy-dependent, or extension-required.

Go-live acceptance certificate

The implementation lead signs only when all companies, branches, currencies, periods, tax registrations, books, dimensions, roles, mappings, imports, reports, and integrations have evidence. The certificate names the product baseline, configuration version, unresolved risks, training completion, support owner, rollback plan, and next review date. “Users attended training” is not the same as “the process can be operated safely.”

Use this runbook with the industry context library, Advanced GL Mapping, Sales Field Guide, API Library, and the industry demonstration cases in the Global Retail Lab.

Wave-control worksheet

For each go-live wave, maintain one row per company and do not mark a wave green because another company passed. Capture legal issuer, base currency, tax registration, books, fiscal periods, branches, warehouses, dimensions, users, integrations, opening balances, and unresolved risks. The wave owner signs the row; finance signs accounting and tax; operations signs stock and fulfilment; security signs permissions; the product owner signs limitations.

Gate	Evidence	Pass condition
Legal setup	Profile export and registration documents	Invoice issuer and tax ID are correct
Chart/mapping	GL version, stage matrix, simulations	Expected debit/credit and refusal cases pass
Master data	Import log and rejected-row file	Counts and duplicate controls reconcile
Security	Role matrix and negative tests	Users can do only approved operations
Integration	Request/response and replay logs	Signatures, scope, idempotency pass
Process	End-to-end rehearsal	Stock, tax, FX, reports, and audit align
Cutover	Opening-balance certificate	Source and OSERP totals agree
Training	Scenario assessment, not attendance	Users complete happy and failure paths
Support	Escalation rota and runbooks	Severity, owner, response time defined

Cutover-day command centre

At cutover start, freeze configuration and announce the timestamp. Take immutable extracts from the old system, record hashes, and save the approved transformation map. Load reference data first, then opening balances and open documents. Run a smoke test for login, company switch, customer search, item search, quotation, receipt, purchase, stock view, report, and API health. Do not allow production users to “test” by creating real journals without a documented test company or reversal plan.

The command centre log records time, decision, owner, affected company, evidence link, and next action. A failed import is not a reason to repeat the entire load blindly. Identify whether the failure is schema, master dependency, duplicate key, permission, validation, or infrastructure; correct the smallest safe scope and rerun with the same import batch key.

First-close control room

The first close should be run as a supervised learning event. Start with sub-ledger counts: invoices, receipts, credit notes, purchase invoices, receipts, stock movements, payroll batches, projects, and bank lines. Compare to source totals by company, branch, currency, and period. Then inspect exceptions: unmapped roles, unallocated cash, negative stock, duplicate external references, tax mismatches, stale FX, open approvals, failed webhooks, and documents advanced without journals.

For each exception, write the reproduction steps and classify it as data, configuration, permission, period, integration, or product limitation. Apply a controlled correction, rerun the report, and link the incident to the relevant Academy guide. A manual spreadsheet adjustment is acceptable only as a temporary reconciliation with owner, expiry, and replacement plan.

International rollout invariants

Across countries, preserve the same semantic identity for company, branch, warehouse, item, partner, document, role, and event even when labels or tax rules differ. Localise tax, language, date, address, bank, and statutory accounts through configuration and translation—not by cloning business logic. Keep group reporting dimensions stable so a global margin report can compare Dubai, Mumbai, Riyadh, and London without confusing a branch with a company.

For every currency, define rate source, quote direction, precision, stale threshold, override role, revaluation account, and realised-FX policy. For every tax regime, define registration, effective dates, place-of-supply rule, evidence, return owner, and credit-note behavior. For every legal entity, define numbering, period lock, approval threshold, retention, and audit access. These are rollout invariants and belong in the acceptance certificate.

Training assessment rubric

Assess an operator on evidence, not memorised clicks. A passing exercise identifies the correct company and branch, selects valid master data, fills every required header and line field, explains the downstream stock/tax/GL effect, handles a deliberate refusal, checks the audit timeline, and produces the report or API response. Score data accuracy, accounting understanding, control discipline, exception handling, and communication separately. A consultant who can complete a happy path but cannot explain a blocked period is not ready to train end users.