If you are reading this, then you are likely following and connected to several other people and companies in the GRC / Audit arena that post solid and insightful content.
For example, Jeff Hare, CPA CISA CIA with ERP Risk Advisors, and his regular updates around their learning content, ERP Armor, and the importance of knowing what is being audited with regular references to the Public Company Accounting Oversight Board (PCAOB).
Or Lewis Hopkins with Seecuring, providing great detail on a myriad of topics ranging from Third Party Risk Management, SOD analysis, and Identity and Access Management.
Likewise with Emma Kelly over at SafePaaS. Here we can regularly find updates on ITACs and ITGCs, their importance, as well as insights into internal controls, audits, and the benefits of policy-based access management.
Today, in light of all of this great content, I’d like to take you down the rabbit hole of ITACs. Specifically, one SOX404b ITAC in the Procure to Pay mega-process for organizations running Oracle R12 from a configuration perspective as well as audit evidence. This ITAC mainly addresses risk mitigation of fraudulent invoices by utilizing Oracle’s Invoice Match option.
The following is what a comprehensive ITAC objective should look like-

When providing evidence for audit, screenshots or reports barely get the job done. It’s important to provide as much information upfront as possible to set the stage for the auditor to understand the control and how the technology functions to support it. Let’s start by adding a narrative and reference on how the configurations support the control objective –

Now we can unpack this objective line by line and look at everything involved from the viewpoints of configuration, audit, and evidence.
1. The Oracle ERP system is configured to automatically match all invoices against approved purchase orders and goods received notes, within a tolerance of 5%.
This is the match option setting (2-way, 3-way, 4-way), plus the tolerance definition by line type. The language states that it must match the approved purchase order AND the goods received. This tells us that the match option is 3-way. To provide accurate configuration evidence in support of this specific configuration, you will need to report the values set at the –
- Purchasing Options
- Supplier Level
- Supplier Site Level
- Purchase Order Shipment level
- The configuration values defined for the tolerances
2. If an invoice does not match the PO number exactly or is outside of the allowed tolerances for amount or quantity, the invoice is placed on hold.
These are the hold definitions and the invoice validation program. If this program has been modified, a copy of its code will need to be maintained in a version control software solution to support ITGCs. You can expect to answer the following questions-
- Proof of the code’s current state (modified or not modified) within the audit period
- If the code has been modified during the current audit period-
- What was modified
- Why was it modified
- Who has access to modify it
- When was it modified
- How was it modified
- Proof of the review and approval of the modification
To provide accurate configuration evidence in support of this specific configuration, you will need to report –
- The configuration values defined for the holds
3. The invoice is reviewed by an authorized employee to determine the cause of the mismatch.
This is an access control and will need to be demonstrated and evidenced by access to the function. You can expect to provide evidence of-
- When the access was granted
- How the access was provisioned
- Who reviewed and approved the provisioning request
4. If the mismatch is due to a data entry error, the invoice is corrected and the hold is released.
This is done by the invoice validation program or the release definitions. If the holds are removed manually using the release definitions, you will need to report-
- The configuration values defined for the release codes
The evidence submitted for the validation program in point 2 supports this statement.
5. If the mismatch is due to another issue, such as a discrepancy between the goods received and the invoice, the issue is resolved before the invoice is paid.
The evidence submitted for the holds, releases, access control to the function, and the validation program in point 2 supports this statement.
You made it to the end! That was a lot for just one control, and it was purely from an IT evidence perspective and does not take into account the necessary evidence that is to be provided to show the actual test of the control. As you can see, this can be incredibly time-consuming to document and deliver without a solution in place.
Need help? H A L E Y Consulting and Advisory Services are here every step of the way. Is your organization running Oracle R12? We have solutions to get your SOX404 audit reporting up and running, reducing audit burden and fatigue, and effectively reducing time to deliver evidence from months to just in time for audit.
Connect with us – Contact – Haley Consulting and Advisory Services (haleycas.com)
Check out our comprehensive suite of services – Services – Haley Consulting and Advisory Services (haleycas.com)