When a treasurer asks for an ‘application audit’, the request usually sits between two familiar exercises. External audit will look at year-end cash and a sample of payments. A vendor health-check will look at version, patches, and whether you are using the module you paid for. Neither reconstructs how a payment, a deal, or a standing-data change actually travels through the live system.
Our work starts with the path, not the module list. Who can raise a payment? Where can the beneficiary be edited after approval? Which file is sent to the bank, and who can touch it after the TMS has released it? Those questions sound operational. They are also the questions that decide whether the control narrative in the last internal-audit report is still true.
Configuration is in scope because it is where policy becomes (or fails to become) a system rule. Approval limits, dual-control flags, editable templates, and the ability to backdate a value date are not ‘IT settings’. They are the treasury mandate, encoded. We read them in the application and compare them with the mandate on paper.
We do not opine on whether you chose the right vendor. We do opine on whether the application, as configured and used, can silently move cash in a way the board did not authorise. That is a narrower, more useful sentence than most statements of work allow.