Transportation IT Audit Software Consulting

PCAOB AS 2201 requires an auditor to test the IT general controls supporting any application control it intends to rely on, and for a transportation company that includes the TMS's rate-calculation and settlement logic, not just the ERP's posting and approval workflows. If access to modify a fuel-surcharge index, a lane rate, or an accessorial-charge rule is not properly restricted and logged inside the TMS, the auditor cannot trust that freight revenue and cost of transportation figures reaching the ERP are accurate — regardless of how well-controlled the ERP itself is. This is why a transportation ITGC scope has to explicitly include the TMS as an in-scope application, with its own access-review, change-management, and computer-operations testing, rather than treating it as an unauditable black box that feeds numbers into the systems that actually get tested.

IT audit software built for this environment maintains a control library that extends beyond the standard ERP-centric ITGC template to include TMS-specific risks: who can modify a fuel-surcharge rate table, who can approve a manual settlement override outside the standard rating logic, and whether configuration changes to accessorial-charge rules go through the same change-management rigor as an ERP configuration change. Without that extension, IT audit teams commonly discover during their first 404(b) year that the TMS was never included in ITGC scope at all, which becomes a significant finding when the external auditor asks how TMS-calculated revenue figures were controlled.

A transportation company's financially relevant access surface spans at least three or four distinct systems — the TMS, a fleet-maintenance platform where capitalization decisions get coded, a treasury or hedge-management tool for fuel derivatives, and the ERP — each typically with its own identity and access model rather than a single unified directory. IT audit software that can pull access data from each of these systems, or at minimum standardize how manually collected access-review evidence from each is documented, materially reduces the reconciliation burden compared to a team assembling four separate spreadsheet exports every testing cycle and manually cross-referencing user lists.

Segregation-of-duties testing carries specific transportation risk worth flagging in the control library: someone with both the ability to modify TMS rate tables and to approve carrier settlements can misstate cost of transportation without a second control catching it, and someone with both fleet-maintenance capitalization-coding access and fixed-asset-subledger posting access can misstate the balance sheet similarly. IT audit software that models these cross-system SoD conflicts explicitly, rather than only testing SoD within each system in isolation, catches a risk that single-system testing structurally cannot see.

Change-ticket sampling — comparing production changes against approved change requests — is a standard ITGC test, but for a transportation company it has to extend to configuration changes that are easy to overlook because they don't look like traditional software deployments: an update to a fuel-surcharge index formula, a new lane-rate table upload, or a fleet-maintenance capitalization-threshold adjustment. These changes are frequently made by operations or finance business users directly inside the TMS or fleet system rather than by IT through a formal deployment pipeline, which means the change-management control has to be designed around business-user configuration changes specifically, not just IT-deployed code releases.

IT audit software that can ingest or connect to TMS and fleet-system audit logs, and test a sample of configuration changes against documented approval evidence, closes a gap that generic ITSM-ticket-based change testing misses entirely — because business-user configuration changes to a rate table or capitalization threshold often never generate an ITSM ticket at all. Evaluating whether a candidate platform can actually reach this data, rather than assuming it can based on a general 'ERP connector' claim, is one of the more consequential due-diligence steps in a transportation IT audit tool selection.