Manufacturing IT Audit Software Consulting

A conventional ITGC scoping exercise focuses on the financial ERP: who has access to post journal entries, who can change the chart of accounts, how application changes are tested and approved before deployment. At a manufacturer, that scope is necessary but insufficient, because financially relevant data — the BOM that drives standard cost, the production and material-issue transactions that drive inventory valuation — often originates and is controlled in systems outside the ERP entirely: a PLM system for engineering data, an MES for shop-floor transactions, sometimes a separate warehouse management system for cycle counts. Restricting ITGC testing to the ERP alone leaves the access and change controls over these upstream systems completely untested, even though a change to a BOM in the PLM system or an unauthorized edit to a standard-cost table has the same financial-statement impact as an unauthorized ERP change.

IT audit software needs to support a scoping methodology that identifies every system feeding financially relevant data into the ERP — not just the ERP's own configuration — and builds ITGC test plans for access management, change management, and computer operations at each one. This is a materially larger scope than a single-system ERP audit, and software that assumes a one-ERP-instance world tends to force awkward workarounds (treating the MES as 'out of scope' by default, for instance) that leave real risk untested.

The specific ITGC that matters most for manufacturing costing accuracy is access to edit released BOMs, standard-cost tables, and overhead absorption rates — configuration that functions financially like a chart-of-accounts change but often sits in a PLM or MES module outside the ERP's own security model, and is therefore easy to leave out of a standard ERP-centric access review. IT audit software should support testing user access listings against a defined population of users who should have BOM or standard-cost edit rights, flagging any access outside that population, and testing whether changes to this configuration flow through the engineering-change-order approval workflow rather than being editable directly.

Change management testing needs a parallel scope extension: application changes to the MES (a new production-transaction type, a modified interface mapping to the ERP) or to the PLM system (a workflow change to the ECO approval sequence) should go through the same test-before-deploy, documented-approval discipline expected of ERP changes, because a defect introduced in an MES upgrade can misstate inventory just as effectively as an ERP defect. Software that only tracks ERP change tickets misses this population entirely.

The interface between the MES and the ERP — and between the PLM system and the ERP for BOM data — is itself a control point that needs dedicated ITGC testing: who can modify the interface mapping configuration, is there a change-approval process for interface logic changes, and does a batch completeness check run automatically to catch dropped or duplicated transactions. IT audit software built for single-system environments often has no natural place to test interface-specific controls, treating them either as part of the source system's change management or ignoring them altogether, when in practice interface configuration changes are frequently made by a small technical team with broad access and limited oversight.

A well-configured ITGC test plan for a manufacturer therefore treats the interface layer as its own tested population — with its own access review (who can change mapping rules), its own change management sample (interface configuration changes in the period), and its own operations control (evidence that batch completeness monitoring ran and any exceptions were resolved) — rather than folding it silently into either the source or target system's test scope.