Designing controls for SAP and ERP: where finance teams systematically lose money.

Every CFO who has lived through an ERP implementation will remember the moment when the project team declared the system “live and stable.” The integrator left. The transformation budget closed. The finance function returned to its operating rhythm. And, in most organisations, the controls that had been designed on paper during the design-and-build phase quietly drifted into something looser in practice.

Six months later, or a year later, a year-end audit surfaces an issue. Authorisations being routed to people who left the company. Vendor master changes made without four-eye review. Journal entries posted directly to the general ledger by users who should not have that level of access. Inventory adjustments processed without documentation. The control framework on paper looks robust. The control framework in operation has gaps that have been costing the business real money.

ERP controls are the area where the difference between “designed” and “operating effectively” matters most. The Companies Act 2013 places explicit obligations on directors under Section 134(5)(e) to confirm the adequacy and operating effectiveness of internal financial controls. Auditors test these under Section 143(3)(i) and report under the ICAI’s Guidance Note on Audit of Internal Financial Controls over Financial Reporting. The framework most organisations have adopted is COSO Internal Control — Integrated Framework (2013), with its IT-control layer assessed through the lens I bring as a Certified Information Systems Auditor.

What follows is the framework I work from when a CFO or CIO asks the firm to look at ERP controls seriously. Seven recurring categories of control failure that produce direct financial leakage. None of them is exotic. Most of them are the consequence of an implementation that prioritised go-live timing over control design — or of an organisation that has scaled past the controls it originally configured.

1 · Segregation of duties — the SoD matrix that does not work

The first control any IT auditor looks at, and the first one most organisations have configured incorrectly.

Segregation of Duties (SoD) is the foundational control in any ERP environment and the area where COSO Internal Control’s principles on control activities apply most clearly. The principle is simple. No single user should be able to execute a complete transaction cycle without independent authorisation — create a vendor, raise a purchase order against that vendor, receive the goods (or record receipt), approve the invoice, and release the payment.

The reality in most mid-cap ERP environments is uncomfortable. The original SoD matrix was designed during implementation with three or four hundred role-conflict rules configured into the system. Over time, business users have requested access exceptions for operational reasons. Each exception was approved individually, on its own merits. The cumulative effect is an authorisation landscape where dozens of users have combinations of access that violate the original SoD design — and where no one is running periodic SoD-conflict reports against the actual production landscape.

The remedy is procedural rather than technical. The SoD matrix must be refreshed periodically — annually at minimum — against the current business reality. SoD-conflict reports must be generated quarterly, reviewed by the finance leadership, and acted upon. Exceptions must be documented, time-bound, and supported by compensating controls. The CFO who cannot, today, produce a current SoD-conflict report for their ERP environment is operating with a foundational ICFR weakness that will surface in the next audit.

2 · The vendor master — where shell-company fraud begins

The single highest-risk master-data control in any finance ERP environment.

Vendor master data is the gateway through which money leaves the organisation. Every payment ever made must trace back to a vendor record. If the vendor master can be changed by a user who can also raise purchase orders or approve invoices, the segregation of duties has collapsed at the most consequential point in the cycle. The ACFE Fraud Tree identifies shell-company billing as the most common asset-misappropriation scheme — and almost every shell-company scheme begins with a vendor-master change that should not have been permitted.

Three control failures in vendor-master administration recur in mid-cap ERPs. First, the team that creates and amends vendor masters also has transactional access in the procure-to-pay cycle. Second, vendor bank-account details can be changed without a documented re-verification protocol — the well-known Business Email Compromise vector. Third, vendor master changes are not subject to a change log that is reviewed independently. Each of these failures, individually, is the kind of finding that an internal audit report flags as a moderate-risk observation. Together, they produce the conditions under which a shell-company billing scheme is operationally feasible.

The remedy involves both ERP configuration and procedural design. Vendor master maintenance must sit with a team independent of procure-to-pay execution. All changes — particularly bank-account changes — must trigger workflow approval by a second independent reviewer. Change logs must be reported monthly to finance leadership. For high-value vendors, an independent annual re-verification of bank-account details against fresh supplier confirmation is good discipline. None of this is expensive to implement. Most of it is missing in mid-cap operations.

3 · Authorisation matrix drift

The signature authority limits configured five years ago that no longer reflect the business.

Every ERP houses an authorisation matrix — the table of monetary thresholds that determines who can approve what. In SAP, this lives in release strategies and approval workflows. In Oracle, in approval hierarchies. In Tally and similar, in user roles and the document-approval modules. The matrix is configured during implementation, reflecting the organisation’s scale and structure at that moment.

Then the business grows. The approval limits that made sense at ₹200 crore revenue make no sense at ₹800 crore. The matrix is not refreshed. Approvers who left the company three years ago are still in the workflow definitions because no one updated them — their approvals are quietly routed to a generic alternate, or worse, are auto-approved through a default. New cost centres and business units are added without thinking through their approval pathways. The matrix becomes a document the auditor reviews and finds inconsistent with the controls the company believes it has.

The remedy is annual review of the authorisation matrix at board or audit-committee level. The current limits should be benchmarked against the current scale and risk profile of the business. The authorisations should be tied to roles, not individuals, with a clear protocol for delegate authority during absence. The system configuration should be audited annually against the documented authorisation policy — not the other way around. A documented authorisation matrix and an actual ERP configuration that do not reconcile is, technically, an ICFR weakness.

4 · Journal entry posting — the unrestricted direct entry path

Where financial-statement manipulation lives, when it lives anywhere.

In every well-controlled ERP, the general ledger is updated through structured business documents — vendor invoices, customer invoices, payments, receipts, goods movements. Direct journal-entry posting to the GL is reserved for a small number of specific scenarios (accruals, provisions, adjustments) and should be restricted to a small number of senior users, with mandatory peer review.

The pattern that recurs in less well-controlled environments is broader access to direct journal-entry posting than the control design contemplated. Junior accountants have access “for convenience.” Month-end provisions are posted by individuals who should be preparing them, not posting them. Reclassification entries are posted without independent review. Reversal entries are posted in subsequent months without anyone re-examining whether they should have been posted at all. The cumulative effect is a GL that contains a meaningful volume of entries with no business-document trail and no documented authorisation.

The remedy is a tight policy on direct journal entries combined with active monitoring. The user population with direct GL posting access should be small (typically two to four senior accountants in a mid-cap business), the entries should require a documented preparer-and-approver pair, and a monthly journal-entry exception report should be reviewed by the financial controller. The COSO framework treats this as a Principle 12 (deploys control activities) and Principle 13 (uses relevant information) consideration. The ISACA standards treat it as a critical preventive and detective control. Both frameworks are right.

5 · Interface and integration controls

Where data crosses systems — and where reconciliation must be designed in.

Modern finance functions rarely operate on a single system. Sales data flows from a CRM into the ERP. Inventory data flows from a warehouse management system. Banking data flows in from electronic banking platforms. Payroll data flows out from the ERP or HRMS to payment platforms. Multi-entity groups consolidate from multiple ERP instances into a group reporting system. Every interface is a place where data can move incorrectly, partially, or not at all — with financial consequences that may take months to surface.

The control discipline that addresses this is interface reconciliation. For every interface, there must be a documented expectation of what should flow (transaction count, value total, control totals) and an automated or manual reconciliation that confirms what did flow. Where the reconciliation does not match, an exception must be raised, investigated, and resolved before the period closes. In well-controlled environments this is invisible — the reconciliations balance, the exceptions are rare, the close happens. In less well-controlled environments, interfaces fail silently and surface as unexplained balances in suspense accounts months later.

For multi-ERP groups — the SAP-at-head-office, Tally-at-branches pattern common in many Indian businesses — interface controls become particularly consequential. The transactional data captured at branches must reconcile to the consolidated GL at head office, with documented timing differences and clear ownership of any unreconciled balance. This is exactly the territory in which the firm operates its proprietary reconciliation tooling — not because the work is technically difficult, but because the discipline is hard to sustain manually at scale.

6 · Change management — the patches, the customisations, the new modules

Where IT General Controls live, and where most ERP environments have weaknesses.

IT General Controls (ITGCs) cover the broad governance of the ERP itself — change management, access management, computer operations, and system development. Of these, change management is where the most common ICFR weaknesses sit in mid-cap ERP environments. Patches applied without testing. Customisations made by developers without documented business approval. New modules implemented in production without parallel running. Configuration changes made by superusers without a change-log entry.

The COSO framework treats change management under Principle 11 (selects and develops general controls over technology). The principle is well established. The practice is often weak — particularly in organisations where the original ERP implementation partner has left and the in-house IT team has accumulated change authority without commensurate process discipline.

The remedy is a documented change-management process with a defined approval workflow, a test environment that is genuinely used, a change advisory board (or equivalent) that reviews production changes before deployment, and a periodic ITGC audit that tests whether the documented process is being followed. For listed companies, this is a Section 143(3)(i) consideration that the statutory auditor will examine; the deficiencies surfaced here tend to be expensive to remediate after the fact.

7 · The exception report nobody reads

Detective controls fail in operation more often than they fail in design.

Every ERP environment produces exception reports — unmatched goods receipts, payments without invoice, invoices without purchase orders, journal entries above threshold, vendor master changes, login failures, after-hours transactions. The reports exist. The challenge is that, in many organisations, they are not actually being read — or they are being read in a tick-box manner without action.

This is the most subtle category of control failure because the controls are designed correctly. The detective controls exist, the reports are generated, the report owners are named. What is missing is the operating effectiveness — the disciplined weekly or monthly review that converts a report into a remediated exception. An auditor who tests this control will sample exception reports from the period, ask to see the evidence of review, and find that the evidence is missing or that the documented review did not produce documented action.

The remedy is harder than the design of the report itself: it is the operational discipline of someone with seniority and authority actually reading the report, acting on the exceptions, and documenting the action. For listed companies under ICFR, this is where the “operating effectiveness” layer of audit testing concentrates. A control that is designed but does not operate effectively is, for ICFR purposes, a control that does not exist. The auditor will treat it as such, and the audit committee will be informed.

How a CFO or CIO should sequence the work.

For a CFO or CIO who recognises some of these categories in their own ERP environment, the path forward is sequential. The work cannot be done all at once, and attempting it that way produces resistance from the business and exhaustion in the finance team.

Begin with a one-time ERP controls diagnostic covering all seven categories. The objective is not yet to remediate — it is to produce a defensible baseline of where the controls stand against the design and against the regulatory framework. The diagnostic typically takes six to eight weeks for a mid-cap business and produces an audit-committee-grade report that can also be used as the input to the next ICFR engagement with the statutory auditor.

From the diagnostic, prioritise by financial-leakage risk. In my experience, the first three categories — SoD, vendor master, authorisation matrix — produce the highest direct financial-loss exposure and are the right place to begin remediation. The middle three — journal-entry control, interface controls, change management — require coordination between finance and IT and benefit from a defined remediation programme over six to nine months. The seventh — exception-report operational discipline — runs in parallel; it is the slowest to instil and the most consequential for ICFR conformance.

The right partner for this work is one whose people hold both finance and IT-audit credentials, can read the ERP configuration without needing a translator, and can present findings at board level. CISA-credentialed practitioners are the conventional choice for the IT-controls layer; partners who hold both CMA/CA and CISA credentials are uncommon in India and are the right pick for the dual finance-and-IT-controls scope.

The honest summary.

ERP controls are not glamorous work. The categories above are not the topics that get discussed at strategy off-sites or featured in the CFO’s board pack. They are the operational layer of the finance function on which everything else depends — and they are the layer most often left to drift after the ERP implementation has been declared complete.

The financial leakage produced by weak ERP controls is real, recurring, and recoverable. A well-designed control architecture — refreshed periodically, tested independently, and supported by exception-report discipline that is actually performed — closes most of the leakage. It also produces an ICFR position that meets the statutory auditor’s requirements under Section 143(3)(i), aligns with the COSO framework that underpins Indian ICFR practice, and supports the directors’ responsibility statement under Section 134(5)(e).

The CFO or CIO who has not seen an independent ERP controls diagnostic in the past two years is almost certainly carrying financial leakage and ICFR exposure that neither yearly external audit nor in-house internal audit will fully surface. The diagnostic does not need to be expensive. It does need to be done by someone with the credential mix to read both the financial and the IT-control layers credibly.

That, in a sentence, is the work the firm does.