The method has eight stages. Figure 1 shows the flow of data and work, and the stages are described below. Table 1, which belongs to the fifth stage, links each control objective to a test.
Control objectives for procure-to-pay, the deviation that signals failure and the event-log test for each
| Control objective | Deviation to detect | Event-log test |
|---|---|---|
| Purchases authorised before commitment | Invoice dated before the order; order sent without approval | Invoice receipt precedes order creation; no approval event before goods receipt |
| Goods received before payment | Payment with no goods receipt | Payment event with no earlier goods receipt on the case |
| Invoice agrees with order and receipt | Price or quantity changed after approval | Order change event after approval without a second approval |
| Approval limits respected | One purchase split into several orders below the limit | Same vendor, requester and day; individual values under the limit, sum above it |
| Segregation of duties | One person creates and approves, or receives and pays | Same user on two incompatible activities within one case |
| Vendors are genuine | Vendor bank details changed shortly before payment | Master data change event within a set number of days before payment |
| No duplicate payments | Same invoice paid twice | Two payment events with matching vendor, amount and reference |
Data and work flow of the proposed continuous auditing arrangement for the procure-to-pay cycle
Start with what the controls are meant to achieve, not with what the data happen to contain. For procure-to-pay the objectives are few: purchases are authorised before commitment, goods are received before payment, invoices agree with orders and receipts, duties are separated, and vendors are genuine. The control framework the company already uses, typically the COSO framework (COSO, 2013), supplies the vocabulary. Scope is then set by materiality and risk: which company codes, which purchasing organisations, which document types.
An event log needs three things for every event: a case identifier, an activity name and a timestamp. The choice of case is the most consequential decision in the whole method. For procurement the purchase order line item is usually the right one, because quantities are received and invoiced by line. Activities are then read from the system's records: requisition created, order created, order approved, order changed, goods received, invoice received, invoice cleared for payment, payment made. In an SAP system these come from the purchasing document tables, the purchase order history, the invoice and accounting documents, and the change log. Attributes worth carrying are the user, vendor, amount, plant and material group.
Before any mining, the log is tested like any other audit evidence. Totals of ordered and invoiced value are agreed to the ledger. Cases that began before the extraction window or were unfinished at its end are identified, since an order with no payment is only an exception if the payment is overdue. Timestamps are examined for batch postings recorded at midnight and for clock differences between modules. Shared or generic user accounts are listed, because they defeat any test of who did what.
A discovery algorithm is run over the log to draw the process actually followed. Methods that guarantee a sound, readable model, such as the inductive miner (Leemans et al., 2013), suit audit use. The auditor lists the variants by frequency: commonly a small number of paths accounts for most cases and a long tail for the rest. The tail is where the audit interest lies, but the main paths must be understood first, with the people who run the process, so that legitimate variations are not mistaken for failures.
The reference model states the permitted paths. It is derived from policy, adjusted for the legitimate variants confirmed in stage 4, and agreed with management. Alongside it sit rules that a path model cannot express, such as limits on who may perform two activities on the same case. Table 1 sets out the core set for a manufacturer.
The log is replayed against the reference model and each rule is evaluated. The output is a list of cases with the reason each failed. Two measures are worth recording for every run: the share of cases that conform, and the value they represent. A process in which nine cases in ten conform but the tenth carries most of the spending is not under control.
What makes the arrangement continuous is repetition. The extraction, log construction and conformance check are scripted and run on a schedule, with each run adding the events since the last. For a mid-sized manufacturer a weekly or monthly cycle is usually enough; daily runs matter only for the few rules, such as changes to vendor bank details, where delay increases the loss. Exceptions go to a queue with an owner and a due date.
Each exception is examined and classified: a control failure, a legitimate variant not yet in the model, or a data artefact. Failures are reported and tracked to correction. Legitimate variants lead to a change in the reference model, approved and dated, so that the same pattern is not raised again. Data artefacts lead to a fix in the extraction. This loop is what stops the exception count from growing until nobody looks at it.