The Controller's
Project Handbook
A Field Guide to Finance Transformation

A loan system migration involves migrating active, legally-binding financial instruments — not historical transaction data. Each loan record carries a borrower obligation, an investor claim, a regulatory classification, and an accounting position. The data is not static. Balances change daily.

Fiserv generates accounting entries and transmits them to the GL via automated interface. This interface is consistently under-scoped. The assumption that Fiserv posts the same way the legacy system did is almost always wrong.

NetSuite's segment architecture must be designed before any transaction is entered. Changing segment structure after go-live is operationally painful. Designing it wrong before go-live means the entire reporting architecture is wrong from day one.

In most organizations, nobody cleanly owns the layer between operational subledgers and the general ledger. IT says it belongs to finance. Finance assumes IT built it correctly. The implementation partner scoped it as a checkbox. The result: posting logic that nobody fully understands, reconciliation procedures built around mystery variances, and close tasks that depend on systems nobody documented.

A subledger is any system that records transactions in more granular detail than the GL. The AR subledger records individual invoice and payment transactions. The loan subledger records individual loan-level balances, accruals, and amortization. The AP subledger records individual vendor invoices and payment runs. The GL receives summarized or detailed journal entries from each subledger through automated interfaces or manual uploads — and the controller is responsible for ensuring those entries are complete, accurate, and timely.

The most consequential design decision in any subledger-to-GL redesign is journal granularity: should the interface post individual transaction-level journals to the GL, or should it summarize and post aggregate journals by period, product, account, or entity?

Suspense accounts exist to capture transactions that cannot be posted cleanly — transactions with missing account codes, missing cost center attributions, rejected mapping logic, or interface failures. In a well-designed architecture, suspense account activity is minimal, cleared daily, and reviewed by a named finance owner. In reality, suspense accounts accumulate unresolved balances that finance inherits during system migrations and discovers in audits.

The reconciliation between subledger and GL is not a reporting artifact — it is a control. And like all controls, it must be designed before the system it relies on is built. The most common failure in subledger-to-GL redesigns is that reconciliation is treated as a post-go-live operational task when it is actually a design requirement that constrains the interface specification.

Conventional software UAT asks: does the feature work as designed? Finance UAT asks: are the accounting outcomes correct? These are completely different questions, and they require completely different test design, test execution, and acceptance criteria. A system that passes IT UAT with 100% of test cases green can still produce fundamentally incorrect accounting on day one of the live close.

A finance UAT test case is not a user story — it is an accounting scenario with a defined expected outcome at the journal entry level. Each test case must specify the transaction type being tested, the exact accounting outcome expected, the evidence required to demonstrate that outcome, and the acceptance criteria that determine pass or fail.

A parallel run runs the legacy system and the new system simultaneously for one or more reporting periods. Its purpose is to confirm that the new system produces materially equivalent accounting outcomes to the legacy system — accounting for any deliberate methodology or structural changes — before the legacy system is retired.

The most dangerous phrase in any finance transformation is "the data is available." It is usually said by an architect, a data engineer, or an implementation partner to reassure the finance team that a system migration or redesign will not break reporting. What they mean is that the raw data exists somewhere in the architecture. What finance needs to know is whether that data has been transformed, validated, and surfaced in a form that finance can use to close books, evidence controls, and produce auditable reports on time.

In most finance projects, the go-live date has some flexibility. In M&A, Day 1 is set by the transaction close — a date determined by legal, regulatory, and deal team dynamics entirely outside finance's control. Finance must be ready to operate on Day 1 regardless of how long it has had to prepare. This fundamental constraint means the Day 1 finance readiness planning must begin as early as possible in the deal process and focus ruthlessly on what has to work versus what can wait.

A Transition Service Agreement is a contract where the seller continues to provide specified services to the buyer after transaction close, for a defined period and price. TSAs are universally used in carve-outs. They are sometimes used in acquisitions where the acquired entity depends on seller infrastructure. Finance leads must understand TSAs operationally — not just as a legal document — because TSAs create real constraints on what finance can and cannot do in the months after close.

A carve-out — selling or spinning off a business unit — requires finance to do something that is operationally extremely difficult: construct standalone financial statements for a business that was never designed to stand alone. The carved entity typically shares systems, shared services, cost allocations, intercompany transactions, and infrastructure with the parent. Finance must unwind all of these in a way that produces auditable, GAAP-compliant standalone financials.

Between Day 1 and full integration, finance operates in an interim state: two COAs, two close processes, two reporting hierarchies, and potentially two ERP systems. This interim state is almost always more complex, more expensive, and longer than planned. Finance leaders who explicitly design the interim operating model — rather than assuming it will take care of itself — dramatically reduce close risk and team burnout during the integration period.

Most steering committees in finance transformation projects are theater. They receive polished status decks from the PM. They hear that the project is green or amber. They nod. They leave. No decisions are made. No escalations are resolved. No genuine risk is surfaced. The project slides to failure while the steering committee believes it is on track.

Close automation projects fail at a remarkably consistent rate, and they do not fail because the tool was bad. They fail because the organization tried to automate a broken close process. The new tool simply automates the old chaos — and the close is now broken and software-dependent instead of broken and spreadsheet-dependent.

Every close automation project begins with a task-level inventory of the current close — by owner, system, timing, and dependency. Most organizations underestimate what they actually do. A typical mid-market controller will produce an initial list of 40 tasks; the real number is usually 120–180 once reconciliations, subledger tie-outs, journal entry reviews, and variance investigations are included.

Finance leaders routinely over-scope automation. A task that runs once per quarter and takes 20 minutes is not worth a 60-hour build. Automation candidates must be ranked by accounting risk reduction AND recurring time saved — and the ranking must survive scrutiny from a CFO who has seen this before.

When a close task is automated, the underlying SOX control does not disappear — it changes form. A manual reconciliation control (prepared by A, reviewed by B, signed by C) becomes a system-assisted control (prepared in tool, reviewed in tool, approved in tool, with electronic evidence). The control narrative must be rewritten. The testing approach must be updated. The auditor must be walked through the new design before the first control testing cycle.

The most common close automation business case is: "reduces close from 10 days to 7 days, freeing up 3 days of accounting capacity." This business case does not survive CFO scrutiny because those 3 days do not translate to headcount reduction or measurable value. A credible business case quantifies actual benefits a CFO cares about.

Reserve methodology projects — whether ASC 450 loss contingency reserves, CECL allowance for credit losses, or operational loss reserves — are accounting policy projects that happen to have a system component. The policy must be defined, documented, governed, and approved before any model is built. Projects that start with the model and back-fill the policy fail in audit.

ASC 450 requires an estimated loss from a loss contingency to be accrued if it is probable that an asset has been impaired or a liability has been incurred, and the amount of loss can be reasonably estimated. The definition of "probable" and "reasonably estimable" drives enormous judgment. The policy document must be specific enough that two different people applying it to the same facts would reach substantially the same conclusion.

CECL replaced the incurred-loss model with a current expected credit loss model — reserves are recorded at origination based on expected losses over the life of the instrument. The implementation is not primarily a model-building exercise. It is a governance, data, and reporting exercise. Most organizations underestimate the data infrastructure needed to support CECL calculation, review, and audit.

The first time a reserve is booked under new methodology, multiple stakeholders have conflicting incentives. FP&A wants to smooth the P&L. Risk wants a higher reserve to reflect true exposure. Audit wants documentation. Management wants predictability. The controller must navigate these while producing a reserve that is defensible, documented, and aligned with the approved policy. Nobody will be fully satisfied. That is the sign of a correctly executed first booking.

ASC 606 is a five-step model: identify the contract, identify performance obligations, determine transaction price, allocate to performance obligations, recognize when each is satisfied. Most organizations understand the model conceptually. The implementation failure happens in translating those five steps into system configuration — contract setup, performance obligation identification logic, SSP allocation, and trigger events that drive recognition.

Advanced Revenue Management modules (NetSuite ARM, Oracle Revenue Management) handle the common ASC 606 patterns well: subscriptions, licenses, services, standard bundled arrangements. They struggle with: variable consideration requiring estimation, significant financing components, customer-specific contract modifications at non-SSP rates, and unusual recognition triggers. Finance teams who assume ARM will handle everything often discover during UAT that 15–20% of contract types require manual journal entries — which means the control environment must accommodate manual revenue entries, which creates SOX exposure.

Standalone Selling Price (SSP) allocation is the single most audit-scrutinized element of ASC 606 implementation. SSP must be established by product, maintained over time, supported by data, and updated when pricing or market conditions change. SSP is not "what we charged last time" — it is an analytical estimate supported by evidence.

Partnership accounting is structurally different from corporate accounting. In a corporation, equity is a residual claim held by shareholders pro rata to share ownership. In a partnership, equity is held in individual partner capital accounts, each with its own contribution history, allocation history, distribution history, and tax basis. Income is not retained — it flows through to partners annually via K-1s under US tax law. Distributions are not dividends — they are draws against capital, sometimes treated as returns of capital, sometimes as allocations of profit, depending on the partnership agreement.

A finance professional who has only worked in corporate accounting will find that familiar concepts either do not apply or apply differently. The general ledger still exists, but the equity section looks nothing like a corporate balance sheet. Revenue recognition still applies, but profit allocation is governed by the partnership agreement — not by accounting standards. Close procedures still exist, but partnership-specific procedures like capital account roll-forwards, waterfall calculations, and K-1 preparation add layers that have no corporate equivalent.

Every partnership accounting system is built around the partner capital account subledger. Each partner has one or more capital accounts — and each account tracks a running balance made up of contributions, allocated profit or loss, distributions, and adjustments. Unlike corporate retained earnings, which is a single aggregated account, partner capital is a collection of individual accounts that must always tie to the corresponding GL control account — and must always be reconcilable to the partnership tax basis calculation.

Partnership profit and loss is not allocated pro rata by default. It is allocated according to the partnership agreement — which defines the waterfall, priority returns, preferred hurdles, performance fees, and any special allocations (such as losses charged to capital, or gains subject to recharacterization). The allocation engine must implement the partnership agreement exactly. Any discrepancy between the system output and the agreement is a legal issue, not just an accounting issue.

A greenfield partnership accounting build requires four architectural components that must be designed together, not in isolation. Buying a GL and bolting on partnership mechanics later produces a system that cannot pass audit. The four components are the partner-level subledger, the allocation engine, the general ledger, and the reporting layer. Each must be explicitly designed for partnership accounting — not adapted from corporate logic.

Partnership accounting controls differ from corporate controls in specific, audit-relevant ways. The three most audit-scrutinized areas are waterfall calculation controls, capital account roll-forward controls, and partner communication controls. Each requires explicit control design — not carried over from corporate control libraries.

Commodity and energy trading partnerships introduce specific accounting mechanics that do not appear in traditional private equity or real estate partnership structures. Mark-to-market accounting on open positions, physical commodity inventory valuation, hedge accounting for derivative positions, and the treatment of physical delivery contracts all interact with partnership allocation logic in ways that a generic fund administration platform may not handle correctly.

A partner revenue share module is not a reporting tool. It is an end-to-end system that (1) pulls transaction volume from the source processing or operational system, (2) applies partner-specific contract rates to compute the revenue share owed, (3) accrues the liability monthly in the general ledger, (4) triggers the payout — whether through a procurement workflow, a payroll-style compensation module, or a treasury auto-wire — and (5) produces the partner-facing statement that reconciles to both the liability booked and the payment made. Every step is controller-owned.

Each layer has a distinct owner, a distinct system, and a distinct control point. The finance lead is responsible for the integrity of the flow end-to-end — not just the GL entries. The most common failure mode is scoping "rev share system" as only Layer 2 (calculation) or only Layer 4 (GL accrual) — leaving the handoffs between layers uncontrolled and the partner statement disconnected from the payment.

The core calculation is simple on paper: partner revenue share = processed volume × contract rate. In practice, every partner contract introduces variations that the engine must handle: tiered rates that step up or down with volume, minimum guarantees, caps, interchange pass-through, adjustments for chargebacks and refunds, and retroactive rate changes. The engine must handle each variation cleanly — and produce an audit trail showing which contract provision drove each calculation.

Partner revenue share payouts are most cleanly handled in a compensation-style module — PeopleSoft Compensation, Workday Compensation, or a purpose-built partner ledger — because compensation modules natively handle the characteristics the rev share flow requires: periodic (usually monthly) calculation cycles, individual-entity ledgers with running balances, approval workflows, holds and adjustments, multi-payment-method support, and tight integration with payroll-style payment execution. Using AP for this purpose forces the partner ledger into an invoice-per-payment model that does not reflect how partner economics actually work.

The revenue share liability must be accrued each month based on volume activity through period end — regardless of whether payment has been processed, approved, or released. Most partner agreements pay on a monthly or quarterly cadence that lags the activity period by 15 to 45 days, which means the liability is virtually always open at period end and the payment is virtually always in a subsequent period.

The final layer is payment execution. The two primary architectures are (a) procurement-routed — where the compensation module generates a payment request that routes through the standard procurement-to-AP workflow, producing a check or ACH through the normal AP payment run, and (b) treasury-direct auto-wire — where the compensation module triggers a direct wire instruction through the treasury system, bypassing AP entirely. Each has different control, timing, and operational characteristics.