Internal Audit Management Software: How Do You Stop Testing Controls With Screenshots and Shared Folders?

The audit function breaks at the evidence, not the workpaper

Here is the scene that repeats every quarter. A senior tests the three way match control. She emails the accounts payable manager and asks for a list of purchase orders over the threshold for the quarter. He runs a report in the ERP (Enterprise Resource Planning), exports it to Excel, and sends it. She samples 25 items, requests supporting documents, screenshots the ERP screen for each one, pastes the screenshots into a workpaper, and files it in a folder on a shared drive named Q3 FY26 Final v4.

Every step of that is defensible except the first one. Nobody can prove the population was complete. The external auditor calls it information produced by the entity and asks how you know the report captured every qualifying purchase order, with what parameters, run at what time, by whom. The honest answer is that the accounts payable manager ran it and you trusted him. That single gap is why so much internal audit work gets tested again by the external auditor instead of relied upon, and reliance is the whole economic argument for the function.

The second failure sits downstream. Issues get raised, owners get assigned, due dates pass, and the follow up lives in a tracking spreadsheet that one person updates before the audit committee meeting. By the time the committee sees remediation status, it is a month old and half of it is optimistic. Meanwhile a control in the revenue cycle gets tested by internal audit in March and by the SOX team in May because the two groups keep separate libraries with different names for the same control.

What the incumbents leave you doing by hand

AuditBoard is the strongest packaged answer for a conventional SOX and internal audit program, and if your control set looks like everyone else's, it will do the job. What it does not do is reach into your specific systems and pull a population with recorded parameters. Connectors handle common cases and the rest arrives as an upload, which puts you back at the same information produced by the entity problem with a nicer interface around it.

Workiva is excellent at the reporting end, particularly where the same content has to flow into external filings under version control. It is document centric by design. Control testing at transaction level, over a population your ERP holds, is not what it was built to be the system of record for.

Diligent and MetricStream both sit in the governance, risk and compliance category, which means they arrive with an opinion about your risk taxonomy, your rating scales and your workflow. If your taxonomy already matches, that is a head start. If your business runs eight legal entities on three ERPs after a decade of acquisitions, you spend the implementation bending the product toward your structure, and every change afterward goes through configuration you may not control.

TeamMate Plus is a serious audit workflow tool with long roots in the profession, particularly for internal audit shops that operate independently of the SOX program. Its centre of gravity is the engagement and the workpaper. Automated testing over full populations, pulled continuously from source systems, is not its core.

The common thread across all five is that they manage the audit process well and treat evidence as an attachment. The work that actually consumes your team is the evidence: getting it, proving it is complete, and testing it. That is where a build earns its money.

What a custom internal audit build has to include

Start with one library. Risks, controls, processes, entities and frameworks in a single model, so a control tested for SOX and a control examined in an operational audit are the same object with two consumers. That alone removes duplicate testing, and it is the cheapest part of the build.

Then engagements. Planning with scope and hours, fieldwork with workpapers, review notes that must be cleared before sign off, and preparer and reviewer roles enforced by the system rather than by a naming convention. Nothing exotic, but it has to be append only. Once a workpaper is signed, changes create a new version with an audit trail, because the first thing a regulator or an external auditor probes is whether conclusions could have been edited after the fact.

The part worth building is the evidence layer. A query definition against your ERP or line of business system, stored as code, run by the system, with the parameters, the run time, the executing account and a hash of the result recorded automatically. That is a complete population you can defend, produced without asking a process owner for anything. On top of it a sampling engine with a recorded seed, so the sample is reproducible three years later, and attribute results captured per item rather than as a summary in a Word file.

Once populations are native, whole categories of control become testable across the full population instead of a sample of 25. Segregation of duties conflicts, journal entries posted by users who should not post, purchase orders raised after the invoice date, user access that survived a termination in the HR (Human Resources) system. Those tests run nightly and raise exceptions as they happen instead of eleven months later. This is the single change that moves an audit function from historian to control.

Then the issue register, and it needs to be built as if the audit committee reads it directly, because eventually they will. Owner, agreed action, due date, automatic escalation when it slips, evidence of remediation attached, and a mandatory re-test before closure. Aging that nobody can quietly reset. Reporting that produces the committee pack from live data rather than from a slide deck someone rebuilt on Sunday.

Cost, timeline and what moves them

A first release runs $75,000 to $160,000 and ships in 12 to 18 weeks. That is the unified risk and control library, engagement workflow with review and sign off, the issue register, and two evidence connectors built properly against your real systems. Two is deliberate: pick the two populations your team spends the most hours chasing, usually something in procure to pay and something in user access.

The full build runs $200,000 to $500,000 across 6 to 12 months. What drives it up: multiple ERPs, which means every connector is built twice; continuous testing over high volume transaction data, which brings real data engineering; entity structures with different control sets per jurisdiction; and external auditor requirements you agree up front, which is worth doing but adds review cycles. What holds it down: one ERP, a control set that is already documented, and a decision to start with the SOX population before extending to operational audit.

The cost nobody budgets is getting your control descriptions into a testable form. Many control descriptions in a mature SOX program are written to survive review rather than to be executed. Turning them into a query and a pass criterion exposes ambiguity that has been sitting there for years, and resolving it takes your control owners' time, not ours.

When buying is the right call

If you are a first year or second year filer with a control set under about 150 controls, one ERP and a small team, buy. AuditBoard or TeamMate will get you running in weeks and your problem right now is discipline, not tooling. The build case appears when the control library outgrows what a packaged taxonomy expresses, when you are testing manually against populations you cannot prove complete, or when the external audit fee keeps rising because reliance on your work keeps falling.

How to choose a developer

Ask them how they would prove a population is complete without asking a process owner. If the answer is a scheduled export, they have not spoken to an external auditor. Recorded parameters, execution account, timestamp and a hash of the result set are the minimum, and a developer who has done this will say so before you ask.

Ask how they handle immutability. Signed workpapers, standing conclusions and issue history must be append only, with new versions rather than edits. If the design is a normal editable table with a last updated column, the whole system fails its first real challenge.

Ask what they have integrated at transaction level. SAP, Oracle, NetSuite, Workday and Active Directory are five different problems, and pulling a defensible population from each has its own traps around delegated authority, posting periods and deleted records. Ask for the specific system and the specific object, not a claim about integrations in general.

Ask who owns the repository and the cloud accounts, and settle it in writing before kickoff. At Digital Heroes the client owns both from the first commit. Your control library and your evidence trail are governance records, and they should never live in an account your developer controls.