Finance ERP discussions often start with modules and screens, but value is realized through end-to-end processes. A finance ERP does not “do finance” on its own; it enables disciplined routines that convert business activity into reliable financial results. When those routines are designed well, finance closes faster, strengthens controls, and reduces the spreadsheet layer that hides risk. When they are designed poorly, the organization goes live with a new user interface while the real work continues in email, side systems, and manual reconciliations.
This chapter describes the core finance processes most organizations enable through a finance ERP, including record-to-report, procure-to-pay, order-to-cash, and asset and project accounting. The goal is not to document every possible variant, but to explain the “spine” of each process—the sequence of activities, the data that must be consistent, the controls that must be embedded, and the decisions that determine whether the process will be scalable. As you read, keep one principle in mind. Process design: the deliberate choice of a small number of standard patterns that can be executed repeatedly, measured consistently, and improved over time.
Each section is written from a practitioner’s view. It highlights what the ERP should own as the system of record, what typically happens upstream or downstream, and where teams most often underestimate effort. Use these sections to anchor scope, staffing, testing, and change leadership, and to define what “good” looks like in daily operations after go-live.
3.1 Record-to-Report
Record-to-report (R2R) is the process that turns transactions into trustworthy financial statements. It begins before period ends, with disciplined in-period posting and controls, and it ends when the organization can explain results, certify balances, and lock the period. A strong R2R design reduces the close from a detective exercise to an exception-management routine.
In a finance ERP, R2R rests on three pillars. Posting discipline: subledgers and interfaces complete on time, with minimal late adjustments. Close orchestration: a clear calendar of tasks, dependencies, and approvals that is executed consistently. Balance integrity: reconciliations and controls that prove the ledger is complete and accurate. If any pillar is weak, teams compensate with manual work, and manual work is the enemy of speed, control, and repeatability.
The practical sequence of R2R can be described in six steps. First, complete operational processing so subledgers are stable, with invoices posted, receipts applied, assets updated, bank feeds received, and interfaces reconciled to control totals. Second, execute accounting activities such as accruals, deferrals, allocations, revaluations, and depreciation. Third, reconcile key accounts and subledger-to-GL ties, resolving exceptions rather than re-computing balances. Fourth, run consolidation activities (if applicable), including ownership updates, currency translation, eliminations, and top-side adjustments under governance. Fifth, produce financial statements and management close packs with traceability back to the ledger. Sixth, certify results and close posting periods to prevent late activity from changing the published outcome.
R2R design decisions show up early in a program, even if teams postpone them. One of the most consequential is the approach to journals. Journal strategy: the balance between automated postings (from subledgers and recurring entries) and manual journals (for judgment-based adjustments). A healthy ERP environment reduces manual journals by fixing root causes—mis-coded transactions, missing interfaces, or inconsistent master data—rather than by adding more reviewers. Establish journal types with distinct rules such as operational corrections, accruals, allocations, statutory adjustments, and reclassifications. Require support and approval levels aligned to risk, and enforce timing rules so late journals do not become the default way to “make numbers work.”
Another decision is how you will manage account reconciliations. The ERP will provide trial balances, subledger listings, and drill-down, but reconciliation quality depends on standard methods. Reconciliation standard: a defined way to prove each key account is correct, including the expected source, the tie-out logic, and acceptable thresholds. For example, a payroll clearing account should reconcile to the payroll system totals by pay period, a bank account should reconcile to statements with defined timing differences, and an intercompany clearing account should reconcile to matched balances and settlement status. The strongest R2R designs reduce the number of “mystery accounts” by limiting suspense usage, automating postings, and designing interfaces that are reconcilable by construction.
Intercompany is where many R2R designs break down because it is both a transaction process and a governance process. In the ERP, intercompany should be identifiable, matchable, and settleable. Intercompany operating model: who owns intercompany agreements, who resolves mismatches, how disputes are escalated, and what service levels apply. If intercompany is “everyone’s problem,” it becomes no one’s problem, and mismatches accumulate until close becomes a crisis. Pair system features (matching reports, automated eliminations, settlement workflows) with behavior rules (cutoffs, tolerance thresholds, and deadlines) that are enforced through leadership cadence.
R2R also depends on period controls and cutoffs. Cutoff discipline: clear rules for when upstream systems stop sending transactions for a period, when late activity is pushed to the next period, and how exceptions are approved. Without cutoffs, teams will always be chasing completeness. With cutoffs, teams can focus on accuracy and explanation. Period controls should be managed intentionally; open periods for specific modules when needed, close them on schedule, and avoid keeping periods open “just in case.” Every open period is an invitation for late postings and rework.
Close orchestration is where the ERP can either provide structure or become a passive ledger. Many organizations use an ERP close cockpit or an integrated close management tool. Regardless of tooling, the design should make work visible and measurable. Define tasks with owners and evidence expectations, not just due dates. Make dependencies explicit, especially those tied to interfaces and upstream activities. Use escalation paths that are based on facts (for example, interface control totals not met by a cutoff time) rather than on end-of-month anxiety.
The following template is a practical starting point for a monthly close calendar. Treat it as a minimum set that you tailor by business complexity, but keep it standardized across entities wherever possible.
- Day -3 to Day 0: Confirm interface schedules and control totals; complete high-volume operational posting; validate master data changes; communicate cutoffs.
- Day 1: Post recurring accruals and reversals; run depreciation; perform initial subledger-to-GL tie-outs; address failed interfaces.
- Day 2: Execute allocations and revaluations; clear suspense and error queues; complete bank reconciliations for key accounts.
- Day 3: Complete intercompany matching and settlement; post approved adjustments; finalize reconciliations for priority accounts.
- Day 4: Run consolidation and eliminations (if applicable); prepare management close pack; perform analytical review and variance explanations.
- Day 5: Final approvals and certifications; lock periods; publish results; capture issues and improvement actions for the next cycle.
R2R testing must be designed as a close rehearsal, not just transaction scripts. Run at least one end-to-end simulation with realistic volumes, interface timing, approvals, reconciliations, and reporting sign-off. Treat gaps as design defects to fix, not workarounds to tolerate.
Finally, define how you will measure success after go-live. Track a small set of KPIs that connect system behavior to outcomes. Close duration: days from period end to published results. Journal volume: manual journals per close with root-cause tags. Reconciliation health: on-time completion and aged exceptions. Intercompany mismatch: unmatched balances and time to resolution.
3.2 Procure-to-Pay
Procure-to-pay (P2P) is where finance intersects with the organization’s spending behavior. It includes how suppliers are created and governed, how commitments are made, how invoices are processed, and how cash leaves the business. In most organizations, P2P is the largest source of transaction volume and the largest opportunity for both efficiency and control.
It is useful to frame P2P as two flows that must stay aligned. Commitment flow: requisition, approval, and purchase order creation that records intent and controls budget. Invoice-to-pay flow: invoice capture, validation, approval, and payment that records obligation and executes settlement. A finance ERP can support both, but many organizations also use specialized procurement tools. The key is consistency—the same suppliers, the same coding structures, and a reconcilable link between commitments and invoices.
Supplier master data is the first control point. Supplier governance: who can create suppliers, what data is mandatory, how duplicates are prevented, and how bank details changes are controlled. Weak supplier governance leads to payment fraud risk, duplicate payments, and messy reporting. Strong governance is not bureaucratic if the process is designed well. Use standardized supplier onboarding, require validation of tax and banking information, and enforce maker-checker controls for sensitive changes. Treat supplier records as financial control objects, not as administrative entries.
The next design decision is how strictly you will use purchasing documents. Many organizations want the control of three-way match, but they allow “non-PO invoices” to bypass the process because it is inconvenient. The result is predictable. POs are used inconsistently, receiving is skipped, and AP becomes an exception factory. A practical approach is to define spend categories and enforce patterns. High-risk and high-value spend should require a PO and receipt. Low-value, low-risk spend can use simplified approvals with clear coding rules. What matters is that exceptions are deliberate and measurable.
Invoice processing is where automation can either accelerate the process or amplify confusion. The ERP typically supports invoice entry, validation rules, and workflow approvals. If an invoice is PO-based, matching can validate quantity and price against PO and goods receipt. If it is non-PO, approvals rely more on cost center owners and budget controls. Exception handling: a structured method to route mismatches (price variance, quantity variance, missing receipt, blocked supplier) to the right owner with clear service levels. When exception handling is undefined, AP holds invoices, business units complain, and late fees become the hidden cost of poor design.
Payment execution is not just a payment run; it is a control environment. The ERP should enforce payment methods, bank account usage, approval steps, and file generation controls. Payment control: the set of rules that ensure only authorized, accurate payments are issued, including dual approvals for payment proposals, segregation between invoice entry and payment release, and secure handling of bank files. If your organization uses banks and payment hubs, design the integration with auditability and reconciliation in mind. The ability to trace from a payment in the bank statement back to the invoice and approval is not optional in a mature environment.
From a working capital perspective, P2P has two levers—timing and accuracy. Timing improves when invoices are processed quickly and disputes are resolved early. Accuracy improves when coding is correct, tax is handled properly, and duplicates are prevented. The ERP enables both by standardizing workflows and by providing visibility into pending work. But P2P outcomes also depend on behavior. If business units delay approvals, no system can create early-payment discounts. If receiving is not performed, matching cannot work.
Design P2P with measurable service levels and roles. In shared services environments, define what the center owns (invoice processing, payment runs, supplier onboarding) and what the business owns (receipting, approvals, dispute resolution). Then align the ERP work queues and dashboards to those responsibilities. Work queue design: configuration and reporting that routes work items (invoices, exceptions, approvals) to the teams that must act, with aging and escalation.
The following checklist captures the core P2P design choices that should be resolved before build is considered stable.
- Spend patterns: Which categories require POs, which allow non-PO, and what thresholds apply?
- Supplier onboarding: What data is mandatory, who approves, and how are duplicates prevented?
- Matching rules: What tolerances apply for price and quantity, and who owns exceptions?
- Approvals: What is the approval chain for requisitions, invoices, and payments, and how are delegations handled?
- Tax handling: How are tax codes determined, validated, and reported for compliance?
- Payment controls: Who can propose, approve, and release payments, and how is bank file security managed?
- Reconciliation: How do AP subledger balances tie to the GL, and how are bank reconciliations executed?
- KPIs: What metrics will be tracked (invoice cycle time, exception rate, discount capture, duplicate payments)?
P2P is also a change management story. Users who previously emailed invoices to AP and waited will now see structured workflows and accountability. Approvers who previously signed the paper will now approve digitally with traceability. Receiving teams who previously relied on informal confirmation will now record receipts. Make these changes explicit and train with realistic scenarios such as a partial receipt, a price mismatch, a blocked supplier, a credit memo, and a rush payment request. These are the moments where adoption is won or lost.
3.3 Order-to-Cash
Order-to-cash (O2C) converts demand into revenue and cash. It includes customer setup, order processing, delivery and billing, revenue accounting implications, collections, and cash application. A strong O2C process reduces revenue leakage, improves customer experience, and accelerates cash conversion. A weak O2C process creates disputes, write-offs, and a permanent gap between sales activity and financial truth.
In many organizations, the ERP is not the system where orders originate; that may be a CRM, an e-commerce platform, or an operational order management system. But finance must ensure that what is billed, collected, and recorded is complete and accurate. Financial spine of O2C: the set of master data, pricing and tax rules, billing controls, and accounting postings that connect operational fulfillment to receivables and revenue.
Customer master data is the starting point and a frequent source of downstream pain. Customer governance: who can create customers, how credit terms and tax details are validated, and how duplicates and parent-child relationships are managed. If customers are duplicated or inconsistently grouped, collections and credit management become inefficient, and reporting by customer segment becomes unreliable. Include bank details for refunds and define rules for changing payment instructions to prevent fraud.
Credit management is often treated as a policy document rather than a system-enabled behavior. A finance ERP can support credit limits, holds, and approval workflows, but only if the organization agrees on how risk is managed. Define who sets credit limits, what triggers a hold (past due aging, exceeded limit, dispute status), and how exceptions are approved. Credit exception: an override of standard credit policy that must be approved, documented, and measurable. If exceptions are invisible, they become the default and credit discipline erodes.
Billing is the control point where revenue leakage is created or prevented. The ERP must be able to generate invoices that are accurate, timely, and compliant with tax and regulatory requirements. If billing is driven by upstream systems, the interface must be reconciled and controlled. If billing is performed in the ERP, pricing and tax determination must be standardized and tested. Either way, ensure that billing supports the business model, whether one-time sales, subscriptions, usage-based billing, milestones, or a mix. The more complex the model, the more important it is to define standard patterns rather than coding every legacy exception.
Revenue accounting is closely linked to O2C, even when revenue recognition is handled in a separate system. Many ERPs support basic revenue recognition rules, but complex models often require specialized revenue management solutions. The key is to define boundaries. The ERP should still maintain the receivable and the billing record, while revenue rules determine timing and classification. Revenue boundary: a clear definition of which system is authoritative for revenue schedules and which is authoritative for billing and receivables, along with reconciliations between them. Without that boundary, finance will reconcile revenue in spreadsheets every month.
Cash application is another area where ERP design can either streamline work or create endless clean-up. Cash may arrive through bank files, lockbox services, payment processors, or manual receipts. The ERP should support matching cash to open items using remittance details, reference IDs, and rules. Cash application strategy: the balance between automated matching and manual application, supported by a clear exception process for short pays, overpays, and unidentified cash. Unapplied cash is not just an inconvenience; it is a working capital and customer relationship issue.
Dispute and deduction management is where O2C often becomes fragmented. If disputes are tracked in email or spreadsheets, finance cannot see why cash is delayed or what actions are required. Some organizations use case management tools integrated with the ERP. Others use ERP workflows and reason codes. The tool matters less than discipline. Dispute taxonomy: a standardized set of dispute reasons (pricing, quantity, quality, tax, contract) that enables trend analysis and root-cause fixes. When disputes are categorized consistently, leadership can address upstream problems rather than negotiating the same issues repeatedly.
Collections performance depends on data quality and clear ownership. Define what the collections team owns (contacts, dunning, promise-to-pay tracking) and what sales or customer service must own (commercial disputes, contract changes). Configure reporting so collectors work from a prioritized list based on value, risk, and aging. Provide visibility into credit holds and dispute status so conversations with customers are informed and consistent.
The following checklist captures the foundational O2C controls and design choices that should be validated in design and again in testing.
- Customer master: Customer creation, grouping, terms, and tax data are governed and controlled.
- Billing completeness: Interfaces or billing runs are reconciled to order/fulfillment control totals.
- Pricing and tax: Determination rules are standardized, tested, and auditable.
- Credit controls: Holds, limits, and exceptions are defined with approvals and reporting.
- Revenue boundary: Authority and reconciliations between billing, receivables, and revenue schedules are explicit.
- Cash application: Automated matching rules exist, and unapplied cash is owned with aging targets.
- Dispute management: Disputes are tracked with reason codes, owners, and service levels.
- Write-offs: Write-off thresholds, approvals, and documentation standards are enforced.
O2C is where cross-functional alignment is most visible. Sales wants speed and flexibility; finance wants control and auditability; customer service wants resolution. A finance ERP program must translate those needs into standard patterns for contract terms, billing cycles, dispute categories, and approval rules for exceptions. Without agreement on those patterns, the ERP will be pressured to accommodate every special deal, and finance will manage complexity through manual adjustments and rework.
3.4 Asset And Project Accounting
Asset and project accounting sits at the intersection of finance policy and operational reality. It is where the organization decides what becomes an asset, how costs are accumulated, when capitalization occurs, and how value is consumed over time. Many ERP programs treat this area as a niche, but it is often a material source of audit findings, close effort, and reporting complexity—especially in asset-intensive industries and organizations with large capital programs.
For fixed assets, the ERP should support the full lifecycle, including acquisition, capitalization, depreciation, impairment, transfer, and retirement. The foundation is policy translated into configuration and behavior. Capitalization policy: the rules that determine what costs can be capitalized, what thresholds apply, what asset classes exist, and how useful lives and depreciation methods are assigned. When policy is clear, automation becomes possible. When policy is vague, teams debate capitalization at month-end and rely on manual journals.
Construction-in-progress (CIP) is a common complexity driver. CIP allows costs to be accumulated while an asset is being built and then capitalized when placed in service. The ERP must support CIP tracking by project or asset under construction, including approvals and documentation. CIP governance: ownership and controls that ensure costs are coded correctly during the build phase, that assets are capitalized promptly when ready, and that stale CIP is investigated rather than carried indefinitely.
Project accounting extends these concepts to broader initiatives such as capital programs, internal development, customer projects, and grants. The ERP should enable cost collection, budget tracking, and rules-driven accounting. For capital projects, project structures should align to how the business manages work, but they must also produce finance outputs, including capitalization, allocations, and reporting by program. For customer projects, the design must support billing rules, revenue recognition implications, and work-in-progress accounting where relevant. Project structure: the hierarchy of projects, tasks, and cost categories that governs how costs and revenue are captured and reported.
Two design decisions determine whether asset and project accounting will be manageable. First is the integration pattern. Time, procurement, and operational systems often feed costs into projects and assets. Define how coding is enforced upstream so costs do not arrive “miscoded” and require rework. Second is the approach to approvals and controls. Capital spending typically requires governance beyond AP invoice approval, such as budget approval, project authorization, and change control. The ERP can enforce pieces of this, but only if the organization commits to using it rather than bypassing it.
Use this checklist to validate readiness for asset and project accounting design.
- Asset classes: Asset classes, useful lives, depreciation methods, and thresholds are defined and agreed with audit.
- CIP approach: CIP tracking, capitalization triggers, and aging review routines are defined.
- Project model: Project structures and cost categories align to both operational management and financial reporting.
- Cost capture: Procurement, time, and expense feeds enforce required coding and are reconcilable.
- Approvals: Capital authorization, budget controls, and change approvals are embedded and evidenced.
- Close integration: Depreciation, capitalization, and project accrual routines are integrated into the close calendar.
When asset and project accounting is designed well, it reduces close effort, strengthens compliance, and gives leadership visibility into capital spend and asset performance. When it is designed poorly, it becomes a permanent spreadsheet layer sitting on top of the ERP. Treat it as a core controllership capability, not an optional add-on.
