Global design is where a finance ERP program becomes an operating model instead of a project. Strategy sets intent and selection provides a platform, but design determines what people will actually do: how spend is authorized, how invoices move, how cash is applied, how intercompany balances are settled, and how close happens without heroics. These are not “configuration preferences.” They are durable choices that shape controllership, productivity, and how much manual work survives after go-live.
The objective is a stable enterprise template: a standard set of process patterns, data definitions, controls, and reporting outputs that can be deployed repeatedly across entities and countries. A strong template does not pretend every location is identical. It defines the core pattern and limits variants to what is truly necessary. The program needs a mechanism to enforce that discipline, resolve disagreements quickly, and prevent late-stage rework. That mechanism is a design authority with real decision rights.
This chapter explains how to run global standardization and design authority, then covers process design for record-to-report, procure-to-pay, and order-to-cash, ending with the chart of accounts and ledger strategy that anchors the entire model.
8.1 Global Process Standardization and Design Authority
Global standardization is not a slogan. It is the controlled reduction of process variants so finance can operate, control, and report at scale. Global process standardization: the deliberate definition of a small number of approved end-to-end patterns that apply across the enterprise, with limited variants only when required by regulation or true business-model differences.
The practical obstacle is that every business unit can explain why its current way is “special.” If you allow those explanations to turn into design requirements, you will recreate legacy complexity inside the new system. The answer is not to ignore local realities. The answer is to make localization a governed exception, supported by evidence, and limited in scope.
That governance is the design authority. Design authority: a decision forum with explicit rights to set global standards, approve controlled variants, and protect the template by catching misalignment early. Design authority should meet frequently, review real design decisions (not presentations), and leave each meeting with recorded outcomes, owners, and due dates.
Start with decision rights. Finance owns finance: accounting policy, process rules, reporting definitions, close discipline, and control intent. IT owns technology: architecture standards, integration patterns, environments, and security tooling constraints. The system integrator should propose options and consequences, but should not become the de facto policy setter because “they’re building it.” If decision rights are unclear, the program will drift into vendor-led design and the client will inherit a model it cannot sustain.
Design authority works best as a small set of connected forums rather than one oversized committee. A Process council: global process owners and senior finance leaders who resolve cross-functional tradeoffs. A Data and reporting council: owners of master data domains, hierarchies, and report definitions who approve structures and change control. A Controls forum: controllership, internal audit, and security leaders who validate segregation of duties, workflow approvals, and evidence requirements. Keep membership tight and authority clear; large groups slow decisions and encourage compromise designs that are complex and still unpopular.
Standardization becomes repeatable when you maintain a pattern library. Pattern library: a curated set of approved designs for recurring scenarios—non-PO invoices, intercompany billing, credit holds, recurring journals, cash application exceptions, and dispute handling. A pattern library is not a theoretical catalog; it is the reference teams use to build, test, train, and roll out. It reduces reinvention and prevents “local innovation” from quietly becoming permanent customization.
Run design using a consistent method. Agree the global objective and the standard pattern first, then identify only the minimum variants, then document the decision in a way build and testing teams can execute without interpretation. This sequence seems obvious, but many programs jump straight into screen-level configuration. When that happens, stakeholders argue about fields and buttons instead of agreeing on roles, controls, and the business rule behind the screen.
Use a simple test for localization requests and apply it relentlessly. Regulatory necessity: required by law, tax rules, or statutory reporting. Business-model necessity:Enterprise value:
When a variance is justified, define it tightly. Controlled variant: a documented deviation with scope boundaries, rationale, configuration approach, and explicit testing and reporting impacts, limited to the minimum entities or scenarios necessary. Controlled variants must have owners and should be reviewed periodically; otherwise, variants only expand.
Keep design artifacts small and useful. At minimum, maintain a decision log, a variant register, and a controls-to-design map that ties key controls to workflow, access rules, and evidence. Add a Day 1 reporting inventory so report needs are visible during design, not discovered during user acceptance testing. These artifacts are not paperwork. They are the operating memory of the program.
Finally, enforce design gates. Design gate: a checkpoint that confirms the proposed design conforms to the template, meets control intent, and supports required reporting before build starts. Gates should be time-boxed and pragmatic, but they must be real. If the program “reviews later,” it will pay for late rework, and rework is the most expensive work in ERP.
- Design authority minimum checklist: clear decision rights, a cadence that matches delivery speed, a pattern library owner, a localization test, a maintained decision log and variant register, and enforceable design gates tied to build start.
8.2 Record-to-Report Process Design
Record-to-report design is where controllership becomes operational. The target is not only fewer days to close. The target is a close that is predictable, explainable, and compliant, where finance spends its time reviewing exceptions rather than rebuilding truth in spreadsheets.
Start with the in-period rhythm. A reliable close begins before period end, with disciplined transaction processing, reconciled interfaces, and visible exception queues. Identify the close-critical dependencies and treat them as part of the close. Close-critical interface: an inbound or outbound feed that must complete by a defined cutoff because reconciliations, allocations, or reporting depend on it. Every close-critical interface should have control totals, monitoring, an error queue, a business owner, and a documented tie-out method.
Define the future close calendar and lock the dependency chain. The calendar should specify operational cutoffs, subledger completion, reconciliation timing, allocation runs, intercompany matching, consolidation activities, reporting certification, and period lock. Where entities require different close timing, treat it as a deliberate variant with a clear rationale; a “different close for everyone” makes consolidation and management reporting permanently fragile.
Period controls must be designed as a controllership mechanism, not a technical afterthought. Decide who can open and close periods, how exceptions are requested, and what evidence is required to reopen a closed period. A simple, effective rule is that reopening is allowed only for defined reasons and requires controller approval, and reopening triggers a documented post-close adjustment process and communications to reporting owners. This discipline protects trust because it creates a clear moment when results are considered final.
Journal governance is a design cornerstone because journals are where errors and judgment enter the ledger. Establish journal categories and enforce them through workflow, access, and documentation standards. Journal category: a controlled class of journals with defined preparers, approvers, required evidence, timing rules, and reversal behavior. Typical categories include operational corrections, accruals, allocations, reclasses, and statutory adjustments. The goal is not to eliminate manual journals, but to reduce uncontrolled posting and ensure every manual adjustment is explainable.
Design the posting model to reduce manual journals over time. Use subledger accounting and interface mapping rules so transactions are coded correctly at source. Automate recurring entries when logic is stable, but require periodic review and variance analysis so “automated” does not mean “unquestioned.” Require clear descriptions and attachments for manual journals, with reference IDs that support traceability from financial statement lines back to business events.
Reconciliations should be engineered, not improvised. Define reconciliation standards by account class and embed them into the close calendar. For AP and AR, reconcile subledger listings to the GL and reconcile interface totals. For cash, reconcile to bank statements with defined timing differences and ownership of open items. For payroll and other external systems, reconcile source totals to ERP postings every period. Reconciliation standard: the defined method, frequency, thresholds, and evidence requirements that prove an account is complete and accurate. Consistent standards make recurring issues visible, which is how the organization moves from month-end firefighting to continuous improvement.
Intercompany design is a frequent close breaker, so it must be deliberate. Require consistent intercompany identifiers at transaction source, standardize intercompany billing and clearing patterns, and define a matching process that runs in-period, not only at month-end. Pair system capability with operating rules: service levels for dispute resolution, cutoffs, and escalation paths. Intercompany service level: a commitment for how quickly trading partners must resolve mismatches and approve settlements. Without service levels, intercompany becomes a negotiation and the close becomes hostage to it.
Allocation design should start simple and be explainable. Use a small set of allocation patterns with clear drivers, owners, and review routines, and ensure driver data is auditable. If allocations require frequent manual overrides, that is usually a business model issue, not a system issue.
Define the consolidation boundary early, whether consolidation sits in the ERP or in a dedicated tool. Confirm entity hierarchies, ownership percentages, currency translation rules, and eliminations approach. Govern top-side adjustments tightly. Top-side adjustment: a consolidation-level journal not recorded in entity ledgers, used for group policy alignment or reclassifications. A limited number may be appropriate; a large number usually indicates inconsistent entity accounting that should be corrected upstream.
Close reporting must be designed as a certified product. Define which reports are produced from ERP, which from consolidation, and which from BI, and define when the close dataset is frozen and signed off. Align period lock and reporting certification so late journals do not silently change published results. Then prove operability through rehearsal: run at least one close simulation with realistic volumes, interface timing, approvals, and reconciliations. Treat gaps as design defects to fix before go-live, and plan the first close as a controlled event with daily triage and explicit decision rights.
- R2R design checklist: close calendar and cutoffs, close-critical interface controls, period control authority, journal categories and workflow, reconciliation standards, intercompany identifiers and settlement rules, allocation patterns and drivers, consolidation boundary and eliminations, and certified reporting outputs with freeze timing.
8.3 Procure-to-Pay Process Design
Procure-to-pay design determines whether spend is controlled early or discovered late. The highest-value standardization usually comes from clarifying spend policies, enforcing supplier governance, and designing exception handling so AP is not forced to chase missing information at month-end.
Start with the commitment process. Define which spend categories require requisitions and purchase orders, what approval thresholds apply, and what coding must be present before a commitment is approved. Even if your organization uses a procurement suite, the principle holds: a commitment is not “approved” unless it carries the cost objects and approvals required for financial posting and reporting.
Supplier master design is the first and most important control gate. Build a standardized onboarding workflow with validation of tax and banking details, duplicate prevention, and a maker-checker model for sensitive changes. Supplier governance: the roles, workflow, and evidence standards that control supplier creation and changes, especially bank detail updates. Treat bank changes as high-risk events with additional verification and logging; payment diversion risk is real and is often enabled by weak master data controls.
Define invoice intake channels and validations. Whether invoices arrive via e-invoicing, OCR, supplier portals, or manual entry, enforce consistent checks: required fields, duplicate detection, tax requirements, and PO references when applicable. Decide when the system blocks an invoice versus places it on a hold, and ensure holds are categorized so root causes can be measured and reduced.
Matching policy drives both efficiency and control. Define which categories use three-way match, two-way match, and controlled non-PO flows. Set match tolerances deliberately. Match tolerance: the allowable price or quantity variance that determines whether an invoice can post automatically or must route to exception handling.
Exception handling must be designed as an operating system with clear ownership. Route exceptions to the party that can resolve the cause: receiving teams for missing receipts, procurement for price mismatches, requestors for coding, and AP for data issues. Define service levels and escalation so invoices do not age unnoticed. Also address the behavioral dependency explicitly: three-way match works only when receiving is performed on time and when POs reflect what is actually ordered. If receiving discipline is weak, exceptions will spike and the business will route around the process.
Design approvals to match risk, not hierarchy. PO-matched invoices within tolerance should flow quickly. Non-PO invoices and threshold breaches should route to cost owners with clear due dates, delegation rules, and escalation. Pay attention to delegation and absence routing; approval bottlenecks are a major driver of cycle time and are often blamed on “the system” when they are actually workflow design gaps.
Payment execution should be treated as a controlled process with separation of duties. Define who can propose payments, who can approve, and who can release bank files. Define payment methods, bank connectivity, and a payment status lifecycle that supports traceability and reconciliation. Build a controlled path for urgent payments so “rush” does not become a bypass of approvals and fraud controls.
Finally, build tax and withholding into the standard pattern. Decide where tax calculation occurs, how tax codes are determined, and what validations prevent common errors. Where withholding applies, ensure supplier records carry the required attributes and that withholding postings and reports are tested with tax stakeholders before go-live.
- P2P design checklist: spend policies and approval thresholds, supplier onboarding and bank-change controls, invoice validations and hold categories, match rules and tolerances, exception queue ownership and SLAs, approval routing and delegation, payment controls with traceable bank integration, and tax/withholding handling.
P2P design is successful when low-risk work flows with minimal touches and high-risk work is visible and controlled without creating a permanent backlog. If the business experiences P2P as unpredictable, it will route around the process, and finance will pay for that routing-around in close rework and weakened controls.
8.4 Order-to-Cash Process Design
Order-to-cash design determines how quickly the organization turns revenue into cash and how well it can explain that conversion. The ERP may not be where orders originate, but finance must define a standard, reconcilable spine from billable events to receivables, cash, and reporting. Without that spine, leakage and disputes become normal operating conditions.
Start with customer master and terms. Standardize customer creation, parent-child relationships, tax attributes, payment terms, and credit settings, and control changes through workflow. Customer governance: the roles and controls that ensure customer records, credit terms, and tax attributes are accurate and auditable. Good governance also enables consistent segmentation for collections and profitability reporting.
Define standard billing patterns that reflect how the business earns revenue: shipment-based, milestone-based, subscription, usage-based, or service completion. Make the billable event explicit and require upstream systems to provide the attributes needed for correct billing and posting. Billable event: the operational trigger that creates an invoice, with required references for pricing, tax, contract, and accounting dimensions. If the billable event is ambiguous, billing becomes manual and disputes increase.
Pricing and adjustments require governance because they drive leakage. Decide where pricing is determined and which system holds the price of record. Define approval rules for credits, write-offs, and manual price overrides, and require reason codes so you can analyze why adjustments occur. Free-form credits without classification create leakage that cannot be managed.
Make credit management operational. Configure credit limits and holds, define what triggers a hold, and define who approves exceptions. Credit exception: an approved override of standard policy that is documented and reportable. Credit holds should be visible to sales and customer service with clear resolution steps; otherwise, finance will be blamed for “surprises” late in the order lifecycle.
Design cash application for automation with honest exception handling. Use reference IDs and remittance data to auto-match receipts where possible, but define ownership for short pays, deductions, and unidentified cash. Establish aging thresholds and escalation. Unapplied cash is not a harmless bucket; it hides customer issues and delays working capital improvements.
Collections design is where O2C becomes tangible for cash. Segment customers by value and risk, then define standard strategies for each segment, including contact cadence, dunning steps, and escalation. Provide collectors with a single view that combines open items, dispute status, promise-to-pay commitments, and credit holds. For strategic accounts, define a collaboration model with sales so collection activity supports the relationship while still protecting cash.
Dispute management should be standardized with a reason taxonomy and clear ownership. Dispute taxonomy: a controlled set of reasons (pricing, quantity, quality, tax, contract) used consistently so trends can be addressed upstream. If disputes are tracked in email, finance cannot manage them; it can only react to them. Include the edge cases that drive workload—refunds, chargebacks, returns—and decide how they are authorized, linked to original transactions, and reconciled.
Align O2C to revenue accounting. If revenue recognition is handled outside the ERP, define reconciliations between billing/receivables and revenue schedules so finance can explain differences without manual mapping. If revenue is recognized in the ERP, define how deferrals, adjustments, and contract changes are processed and approved within the workflow. Define KPIs early and use them to validate the design: invoice cycle time, dispute aging, cash match rate, unapplied cash aging, and write-off volume by reason.
- O2C design checklist: customer governance, standard billing patterns and billable events, pricing and credit approval controls, credit limit and hold rules, cash application automation and exception routing, collections segmentation and dashboards, dispute taxonomy and ownership, and revenue-to-billing reconciliation with KPIs.
8.5 Chart of Accounts and Ledger Strategy
The chart of accounts and ledger strategy is the structural backbone of the global template. It defines how transactions are classified, how results roll up, and how statutory and management views reconcile. The best designs capture only the dimensions that must be known at the moment of posting and rely on governed hierarchies and reporting layers for flexible analysis.
Chart of accounts strategy: the design of accounts and posting dimensions that enables required reporting with minimal transaction coding burden and strong governance. Start with principles: keep segments stable, avoid overlapping meanings, and design for usability so coding accuracy is achievable without constant correction journals. A practical COA design starts with reporting needs and works backward to posting requirements. Identify the close reports that must be produced (statutory statements, management P&Ls, balance sheet analysis, key KPIs), then determine which dimensions must be captured on transactions to automate those outputs. Anything that cannot be captured reliably at posting time belongs in a reporting layer, not forced into GL coding.
Design segments with intent. Natural accounts represent the “what” (revenue type, expense type, asset class), while dimensions capture the “where” and “why” (entity, responsibility center, product line, project, intercompany). Use hierarchies for rollups rather than creating new natural accounts for every reporting layout. Where statutory reporting requires specific groupings, represent them through controlled hierarchies and mappings so the natural account list remains stable.
Ledger design determines how you support multiple accounting bases and currencies. Ledger: a defined set of books by accounting basis, currency, and calendar. Decide whether differences between statutory and group reporting are handled through parallel ledgers, reporting layers, or controlled adjustment processes, and define how differences are reconciled and evidenced. Decide how you handle post-close adjustments: a formal adjustment period, a controlled post-close journal process, or both, but avoid ad hoc reopening without governance. Define currency rate sources and timing rules for translation and revaluation, and standardize calendars where possible to reduce consolidation friction.
Governance keeps the structure from degrading. COA governance: approval and change control for new accounts and values, hierarchy updates, naming conventions, effective dating, and impact assessment on reports and interfaces. During migration, treat mapping as a controlled artifact with owners, versioning, and validation through trial balance conversions and parallel reporting comparisons. Mapping errors are rarely obvious until close, so validate early and repeatedly.
- COA and ledger design checklist: segment intent and minimum posting dimensions, hierarchy strategy for statutory and management rollups, entity and intercompany identifiers, ledger and accounting-basis approach, currency and calendar rules, COA change governance, and mapping validation for conversion and comparatives.
A strong COA and ledger strategy reduces complexity everywhere: fewer interfaces require custom logic, fewer reports rely on manual mapping, and standard processes become easier to execute because the system language is consistent, and keeps the global template sustainable.
