Systems, ERP & Application Audit

It is an independent check of whether the controls built into your ERP or core business application — who can do what, what approvals are required, how data moves between systems — actually work the way management believes they do. It goes beyond financial statement audit to test the system itself: user access, approval workflows, automated checks like three-way matching, and whether data flowing between your ERP and other systems (banking, payroll, GST tools) is complete and accurate.

There is no standalone statute that mandates a periodic ERP audit by name. However, it is closely linked to obligations that are mandatory: the Board's certification of Internal Financial Controls over Financial Reporting under Section 134(5)(e) of the Companies Act 2013 (for listed companies), the statutory auditor's IFC opinion under Section 143(3)(i) for applicable companies, and, for certain regulated entities (banks, NBFCs, listed companies), specific regulator expectations around IT governance. In practice, an ERP audit is the mechanism by which the underlying application controls supporting IFC certification are actually tested at a level of technical depth the standard statutory audit procedures may not reach.

The statutory auditor's IFC testing is scoped to controls material to the specific financial statement assertions and line items being audited — it is a subset, not a comprehensive review of the ERP. A dedicated Systems/ERP Audit goes deeper: full segregation-of-duties analysis across the user base, complete access recertification testing, interface reconciliation across all satellite systems, and master data integrity review — regardless of whether a specific control is deemed 'material' for the current year's financial statement opinion.

PNPC's IT-audit-trained team has experience across the ERP systems most commonly used by Indian mid-market and enterprise clients, including SAP (ECC and S/4HANA), Oracle (E-Business Suite and Fusion), Microsoft Dynamics 365, NetSuite, Tally Prime with add-on modules, and Zoho Books/Zoho One implementations. The audit methodology — ITGC, SoD, application controls, interface testing, data analytics — is consistent across platforms, but the specific configuration tables, role structures, and known risk areas we test are tailored to each application's architecture.

Segregation of duties means no single user should be able to both execute and approve/control the same transaction end-to-end — for example, creating a vendor master record and also approving payments to that vendor, or raising a purchase order and approving the corresponding invoice. When SoD is violated, a single compromised or dishonest user can commit and conceal fraud without needing a second party's collusion. In ERP systems, SoD conflicts accumulate silently over time as employees change roles and IT grants incremental access without revoking the old access.

For a system that has just gone live, the more relevant engagement in the first few months is often a post-implementation review focused on go-live readiness — confirming data migration completeness, initial access grants being appropriate, and configuration matching the approved design. A full-cycle Systems/ERP Audit as described here is typically most valuable once the system has been in live operation for at least one full reporting cycle (so there is a transaction history to test) and ideally after the first set of access changes from staff movement.

The audit team requires read-only access to user administration tables, configuration settings, and transaction data extracts — no change or write access to your production environment is required or requested at any stage. Where direct system access is not feasible for security reasons, we work with your IT team to obtain the required data extracts on an agreed schedule instead.

For a mid-sized single-ERP organisation with a handful of modules and locations in scope, a realistic first-cycle timeline is 8–10 weeks from kickoff to Audit Committee presentation. Multi-entity groups, multiple ERPs, heavy customisation, or a larger number of interfaced satellite systems extend this. Subsequent annual cycles are typically faster once baseline documentation, the risk assessment, and the SoD matrix already exist from the prior cycle.

Each finding documents the specific control gap identified (for example, '14 users hold both vendor-master-creation and payment-approval access'), the risk it creates, and a practical, system-configurable recommendation. Severity is rated Critical, High, Medium, or Low based on the combination of likelihood and potential financial or reputational impact — a Critical finding typically indicates an active exposure (for example, unrevoked access for an exited employee with payment authority), while a Low finding might be a documentation gap with no immediate transactional risk.

The report and the Audit Committee/Board presentation are addressed to your organisation — typically the Audit Committee, CFO, and CISO/IT Head. Sharing the report with your statutory auditor is your decision; many clients choose to share it (with the engagement CA's involvement) because it strengthens the statutory auditor's own IFC evidence base and can reduce duplicated testing, but PNPC does not share it with any third party without your explicit consent.

No. A Systems/ERP Audit tests application-layer controls — access, configuration, workflows, interfaces, data integrity. It does not test network perimeter security, external attack surface, or infrastructure vulnerabilities, which require a dedicated VAPT (Vulnerability Assessment and Penetration Testing) engagement using different tools and methodology. The two engagements are complementary — an organisation with strong ERP application controls can still be exposed at the infrastructure layer, and vice versa.

ITGC covers the foundational controls that support every application control riding on top of the system: user access provisioning and de-provisioning, periodic access recertification, change management for any configuration or code change to the system, and IT operations controls such as backup and disaster recovery. If ITGC is weak — for example, exited employees are not promptly de-provisioned, or configuration changes are made without approval — then even a well-designed application control (like a three-way match) cannot be relied upon, because the environment around it is not controlled.

Three-way match is an automated control that verifies a vendor invoice against both the purchase order and the goods receipt note before allowing payment — ensuring the organisation only pays for what was ordered and actually received, at the agreed price. It is one of the most common automated controls configured in ERPs to prevent overpayment, duplicate payment, and payment for goods never received. We specifically test whether the configured tolerance limits (the permitted variance between PO, GRN, and invoice amounts) are reasonable and whether the control can be bypassed through manual override, and if so, by whom and how often.

Yes. For heavily customised systems, we run a short discovery phase before finalising the detailed test plan — reviewing the specific customisations, custom workflows, and any bespoke reports or interfaces built on top of the standard ERP. Applying a generic, vendor-standard checklist to a heavily customised system typically produces findings that are either irrelevant (testing standard controls that were deliberately replaced) or that miss the actual risk (custom code or workflows that were never independently reviewed).

Master data — vendor records, customer records, chart of accounts, tax codes — is the foundational reference data that every transaction in the ERP draws upon. Poor master data governance (duplicate vendor records, dormant-but-active vendors, uncontrolled changes to bank account details on a vendor master) is a common vector for both genuine error and deliberate fraud, such as redirecting a payment to a fraudulently altered bank account. We test who can create or modify master data, whether changes require independent approval, and whether the master data itself contains anomalies like duplicate PANs or bank accounts shared across supposedly unrelated vendors.

We reconcile the transaction data extracted from the ERP (or the e-invoicing/e-way bill utility feeding off it) against the actual GSTR-1 and GSTR-3B returns filed for the corresponding period, checking for completeness (all applicable transactions captured), accuracy (correct HSN/SAC codes and tax rates applied by the system configuration), and timeliness. Where the ERP auto-generates e-invoices or e-way bills, we also test whether the interface between the ERP and the government's Invoice Registration Portal (IRP) or e-way bill portal is functioning without silent data loss or duplication.

We do not wait for the final report to communicate a Critical finding — such as active, unrevoked payment-approval access for an employee who left the organisation months ago, or an unauthorised configuration change that bypasses an approval workflow. Critical findings are escalated to management (and, depending on severity, the Audit Committee Chair) immediately upon confirmation, so remediation can begin before the final report is even drafted.

Institutional investors and IPO due diligence teams routinely examine the maturity of financial systems and controls as part of their assessment — an unaudited ERP with unknown access risk and unreconciled interfaces is a red flag that can trigger valuation adjustments, specific indemnities, or deal delays. A completed ERP audit with a clean or well-remediated findings history is concrete, independently-verified evidence of control maturity that can be included directly in the data room.

The core methodology — ITGC, SoD, application controls, interfaces, data integrity — is the same, but the specific testing approach differs. For SaaS ERPs (e.g., NetSuite, cloud SAP S/4HANA, Dynamics 365 Business Central), infrastructure-level controls like physical data centre security and underlying network security are the vendor's responsibility under the shared-responsibility model, so we focus our testing on the controls your organisation configures within the application — access, workflow, and configuration — rather than duplicating vendor-level infrastructure assurance (which is typically covered by the vendor's own SOC 2 or ISO 27001 certification, which we review as supporting evidence).

PNPC's core deliverable is the independent audit and findings report. We do provide practical, implementable remediation recommendations for every finding, and we track remediation status through the follow-up validation cycle. Where a client wants hands-on support implementing a specific remediation (for example, redesigning the approval matrix or conducting a full access recertification exercise), we can scope that as a separate advisory engagement — kept distinct from the audit itself to preserve independence for the following audit cycle.

Most organisations benefit from an annual cycle, aligned with the statutory audit calendar so findings can inform (and be informed by) the year's IFC testing. Organisations with lower risk profiles, simpler ERP landscapes, and a clean prior-cycle result sometimes move to a bi-annual (every two years) cycle, supplemented by targeted reviews after any major system change (upgrade, new module go-live, new entity onboarding). Any major ERP change — migration, upgrade, new interface — should trigger an interim scoped review rather than waiting for the next scheduled full cycle.

A generic IT security checklist typically verifies presence/absence of policies and generic technical settings (password complexity, firewall presence) without testing whether financially significant application controls actually operate as designed on live transaction data. PNPC's Systems/ERP Audit is built by Chartered Accountants with IT audit training specifically to bridge financial control understanding with technical testing — we test actual SoD conflicts using real access data, actual three-way match enforcement using real transaction samples, and actual interface completeness using real reconciliations, not a checklist of yes/no policy questions.

Yes. PNPC has operating offices in Chennai, Bangalore, Hyderabad, and Dubai. For groups running a single ERP instance across an Indian entity and a UAE entity — a common structure for cross-border businesses — we test the controls consistently across both entities' data and users within the same engagement, and factor in relevant differences such as UAE VAT/Corporate Tax reporting requirements alongside Indian GST requirements where the ERP handles both.

PNPC's Systems/ERP Audit engagements are led by practising Chartered Accountants with specific information systems audit training and experience, supported by technical specialists with ERP-platform-specific configuration knowledge where the engagement requires it (for example, SAP Basis-level access review expertise for SAP engagements). The CA leadership ensures findings are interpreted through the lens of actual financial statement and governance risk, not purely technical IT risk in isolation.

PNPC agrees a fixed, written fee for each ERP audit engagement, scoped to the specific number of modules, entities, locations, and interfaces in the audit's coverage. Fees depend materially on ERP complexity, the number of users and locations, the extent of customisation, and whether it is a first-cycle (baseline-building) engagement or a repeat annual cycle. We provide a written scope and fee proposal after the initial scoping discussion — before any fieldwork begins.

A pure IT security firm typically lacks the Chartered Accountant's grounding in financial statement risk, IFC requirements, and Companies Act governance obligations — they can tell you a password policy is weak but may not connect an SoD conflict to its financial reporting and fraud implications. A generic compliance vendor often runs a templated checklist regardless of your specific ERP configuration. PNPC combines practising CA judgment — the same judgment applied in statutory audit and IFC testing — with hands-on ERP-specific technical testing, and we are the same firm your Board can call on for the statutory audit, internal audit, and every other assurance need across the company's life.

Landscape mapping and risk assessment; audit charter and access provisioning coordination; full ITGC review including access provisioning/de-provisioning testing; comprehensive segregation-of-duties analysis; automated/application control testing including three-way match and approval workflows; interface and reconciliation testing across satellite systems including GST/e-invoicing; master data governance review; data analytics on full transaction populations where feasible; severity-rated findings report; management response collection; Audit Committee/Board presentation; and a follow-up validation cycle to confirm remediation was genuinely implemented.

Where a client already has an internal audit function (in-house or outsourced, including PNPC's own Internal Audit service), the Systems/ERP Audit is typically either commissioned as a specific cycle within the broader internal audit plan, or run as a standalone deep-dive that feeds findings into the internal audit's overall risk register. We coordinate scope with the existing internal audit function to avoid duplicated testing and to ensure IT/ERP risk is properly represented in the annual risk assessment that drives the broader internal audit plan.

Yes. While the ideal reporting line for ERP audit findings is a formally constituted Audit Committee (mandatory for listed companies and certain classes of public companies under Section 177 of the Companies Act), many private companies without a mandatory Audit Committee still commission ERP audits and receive findings directly through the Board or a designated senior management sponsor (typically the CFO). The value of the audit itself is not diminished by the absence of a formal committee structure, though we do recommend at least a Board-level briefing for any Critical or High findings.

Yes, and it is often more directly relevant for such entities. RBI has issued specific IT governance, risk, and control guidelines for banks and NBFCs (including master directions on IT governance and cybersecurity), and core banking or lending management systems fall squarely within scope of the same ITGC, application control, and data integrity testing methodology used for any ERP. For regulated entities, we align the audit scope and reporting format to the specific regulatory guideline in force, in addition to the general Companies Act and IFC considerations relevant to any company.

No. The engagement includes the formal Audit Committee/Board presentation, a management response collection process, and a follow-up validation cycle in the subsequent period to independently confirm remediation actually happened. PNPC remains available for clarification questions on findings throughout the remediation period at no additional charge within the engagement, consistent with our approach across every PNPC service — we do not consider the engagement complete until the findings have been acted upon, not merely delivered.