Expertise

Finance, Controlling & Controls

Finance and Controls connects decisions across the estate. Finance is where SAP decisions become visible, and where a design that looked reasonable in a workshop meets period close.

A transaction spine crossed by controls A spine runs from transactions to reporting. A control layer crosses it from above and data ownership underpins it from below, with reconciliation points marked along the spine. Controls Transactions General ledger Management accounting Reporting Reconcile Reconcile Data ownership A transaction spine crossed by controls A spine runs from transactions to reporting. A control layer crosses it from above and data ownership underpins it from below, with reconciliation points marked along the spine. Controls Transactions General ledger Reconcile Management accounting Reconcile Reporting Data ownership

The boundary

Controls are not a stage at the end

The record-to-report spine is easy to draw and hard to run. What decides whether it holds is the layer across it — who may do what, how that is evidenced, and how change reaches production.

Where the finance spine meets the control layer The record-to-report spine runs from transactions through the general ledger and management accounting to reporting. A control layer spans all of it: access and segregation of duties, process controls, and change control. Reconciliation points sit between the ledger and management accounting, and between management accounting and reporting. A data-ownership foundation runs beneath the whole diagram. Record to report 1 Transactions 2 General ledger 3 Management accounting 4 Reporting Reconcile Reconcile Control layer Across every stage, not after them Data ownership Everything above rests on it Where the finance spine meets the control layer The record-to-report spine runs from transactions through the general ledger and management accounting to reporting. A control layer spans all of it: access and segregation of duties, process controls, and change control. Reconciliation points sit between the ledger and management accounting, and between management accounting and reporting. A data-ownership foundation runs beneath the whole diagram. 1 Transactions 2 General ledger 3 Management accounting 4 Reporting Control layer Across every stage Data ownership Everything rests on it
Controls are not a stage after reporting. They sit across the whole spine, and everything on it rests on someone owning the master data.
  1. Transactions — Source processes and the interfaces that feed them.
  2. General ledger — Postings, period close and the statutory view.
  3. Management accounting — Controlling, CO-PA and allocations.
  4. Reporting — Statutory and management output.
  5. Control layer — access and segregation of duties, process controls and change control, applied across every stage rather than after them.
  6. Data ownership — who defines a valid master record, and who answers when it is wrong.

Treating controls as a final stage can delay discovery. Review control ownership and evidence across the full process.

Underneath both sits data ownership. Where nobody can name the person who decides what a valid master record looks like, reconciliation depends on explicit ownership and evidence.

Operating model

Decisions that shape everything downstream

Settling these earlier can reduce later rework once a transition is under way.

  1. Where the ledger boundary sits

    How many legal entities, how many ledgers, and which of them exist for statutory reasons rather than management ones. The answer shapes how much of a later change has to be applied more than once.

  2. Chart of accounts and its dimensions

    What the account structure is being asked to carry that a dimension should carry instead. Accounts that encode abandoned reporting structures constrain what a redesign can express.

  3. Central Finance: staging or destination

    Whether Central Finance is a stepping stone toward a single system or a permanent architecture. Both are legitimate, and the two imply different configuration, extension, integration and data responsibilities.

  4. Group and statutory alignment

    Where consolidation, group reporting and local statutory requirements diverge, and which of those divergences the system should represent rather than a spreadsheet.

Record to report

Where the close actually spends its time

  1. Close sequence and dependencies

    What must complete before what, which steps are genuinely serial, and where the close is waiting on a person rather than a system.

  2. Reconciliation points

    Where the ledger and management accounting are expected to agree, how that agreement is demonstrated, and what happens when it does not.

  3. Allocations and assessments

    Whether allocation logic is understood by the people who own the result, and whether it can be explained to an auditor without reverse-engineering configuration.

  4. Manual intervention

    Which journals are posted by hand every period, and which of those are covering a process gap rather than an exception.

CO-PA and profitability

Margin is a design decision before it is a number

In SAP S/4HANA, Margin Analysis is the recommended profitability-analysis approach and remains reconciled with financial accounting. Costing-based CO-PA can still be relevant; the design question is which view the operating model and reporting obligations require.

  1. What profitability is measured on

    Product, customer, contract, region, venture — and whether the characteristics that carry those views actually exist in the source data.

  2. Costing-based or account-based

    A design question with long consequences for reconciliation, reporting and the effort of every future change.

  3. Derivation and its blind spots

    Where characteristic derivation quietly fails, and what the reported margin looks like when it does.

Access, process and change controls

What has to hold when the estate changes

  1. Access and segregation of duties

    What a role can do in combination, not in isolation — the conflicts that matter are the ones spanning two roles nobody reviews together.

  2. Process controls

    Which controls are automated, which are asserted, and which exist only in a document describing how the process used to work.

  3. Change control

    How configuration and code reach production, who approves, and whether the evidence would satisfy someone who was not in the room.

  4. Evidence and auditability

    Whether the trail from a reported figure back to its source survives contact with an auditor without a manual reconstruction.

Data ownership and reconciliation readiness

Before any of the above can be assessed usefully, two questions need answers: who owns each master-data domain, and where the estate is expected to reconcile. Where both have an answer, later decisions rest on something settled. Where they do not, the gap tends to surface during a transition rather than before it.

Reviewing your finance and controls design?

Tell us where the close slows down and where the reconciliations argue.

info@cal-assoc.com

8003 Bulrush Canyon Trail, Katy, TX 77494 · the Greater Houston area