Why Trace a Transaction?
A control description explains what is supposed to happen. A process walkthrough follows a specific transaction through the actual process to understand where decisions and controls occur, who performs them, and what records are created. This helps an assessor check whether the described process matches the one in use and whether the expected evidence exists.
A walkthrough is useful when processes involve several teams, systems, or approvals. A transaction may pass through underwriting, policy administration, and finance, for example. Following its identifiers and records across those steps can reveal an omitted handoff, an undocumented manual action, or a control that is performed differently from its written description.
The objective is not simply to collect documents. For each control, ask what risk it addresses, what action should occur, when it should occur, who is responsible, and what reliable evidence would show that it did occur. Those questions link the process narrative to the evidence.
Build the Trace Before Evaluating the Evidence
Start with a transaction that can be identified unambiguously, such as a policy number, claim number, or payment reference. Establish its starting point and final recorded outcome, then trace through each relevant handoff. At each step, record the process owner, system or record used, control activity, and evidence expected.
State the risk and control objective being examined, the process segment in scope, and the transaction identifier. Avoid expanding the walkthrough into an assessment of unrelated controls.
Ask the process owner to describe the steps, responsibilities, systems, approvals, and treatment of exceptions. Compare the explanation with current procedures, but do not treat a written procedure as proof that the steps actually occurred.
Follow the same transaction identifier through source records, system screens or logs, approvals, and final records. Confirm that each artifact refers to the selected transaction and the relevant event.
Check whether the evidence supports the required action, responsible person, timing, authorization, and outcome. Where the control requires an exception to be resolved, trace that resolution too.
State what the walkthrough supports, what could not be substantiated, and what further work would be needed. Do not generalize a transaction-specific observation to the full period without appropriate additional testing.
What Makes Evidence Persuasive?
Evidence is most useful when it is relevant to the control objective, tied to the transaction, and sufficiently reliable for the assertion being made. A dated approval linked to a policy number may support that an authorized person approved that policy. A general statement that approvals are normally obtained does not show that this particular policy was approved.
| Evidence source | What it can support | Points to verify |
|---|---|---|
| Interview or inquiry | Process understanding, roles, rationale, and descriptions of manual steps | Who was interviewed, whether the person performs the activity, and whether other evidence corroborates the explanation |
| Business record | Transaction details, review marks, completed checklists, or recorded decisions | Transaction linkage, date, completeness, and whether the record was created contemporaneously |
| System log or workflow history | User actions, system events, timestamps, routing, and status changes | Whether the log is complete, what each event means, user identity, and whether timestamps and system settings are dependable |
| Approval or authorization | Evidence that a required decision or sign-off was recorded | Approver authority, approval scope, timing relative to the controlled action, and connection to the transaction |
| Observation or reperformance | How a procedure is currently performed or whether a calculation/action can be repeated | Whether the observed or repeated activity is the same control and transaction; a demonstration alone does not prove prior operation |
Reliability depends on the evidence and the claim being made. A system-generated log can be strong evidence of a recorded user action when the user identity, timestamps, and log completeness are dependable. If those features are not established, the log may be less conclusive than it first appears. Similarly, an approval image may show a signature or status but not establish that the approver had authority or reviewed the relevant information.
Why Transaction Linkage Matters
The reasoning behind a walkthrough is a chain, not a checklist of documents. Suppose the control objective is to prevent a policy from being bound above an underwriter's authority. A procedure manual establishes the expected rule. A policy record identifies the transaction. An authority table establishes the applicable limit. A workflow record can show the premium or exposure submitted for approval, and a dated approval can show whether an authorized referral occurred before binding.
Each item addresses a different part of the claim. If the approval is not tied to the policy, it may relate to another risk. If it is dated after binding, it may show retrospective review rather than preventive authorization. If the limit table is outdated, the comparison may not establish the correct authority. The conclusion is only as strong as the weakest essential link.
This chain explains why several mutually consistent sources can be more persuasive than one source alone: each can corroborate a different link. It does not mean that counting documents makes evidence reliable. Three records copied from the same unverified source do not necessarily provide three independent confirmations.
Worked Example: Underwriting Referral Before Binding
Scenario. A hypothetical insurer requires referral to a senior underwriter before binding a commercial property policy whenever the requested limit exceeds $2.0 million. A selected policy has a requested limit of $2.4 million and a recorded bind date of March 18. Determine what the walkthrough evidence supports.
Method. Trace the policy identifier through the submission, authority rule, referral, approval, and bind record. Test the timing and linkage of each item rather than relying on the underwriter's description alone.
Step 1: Establish the trigger. The submission record identifies policy P-8041 and a requested limit of $2.4 million. The applicable authority table, effective on March 18, sets the referral threshold at $2.0 million. Since $2.4 million is greater than $2.0 million, referral was required.
Step 2: Trace the referral and approval. A workflow entry for P-8041 shows referral to a senior underwriter on March 16. The approval record identifies the same policy and shows approval by an individual listed as a senior underwriter in the authority roster. The approval timestamp is March 17 at 10:20 a.m.
Step 3: Compare approval timing with binding. The policy administration record shows binding on March 18 at 2:00 p.m. March 17 at 10:20 a.m. precedes March 18 at 2:00 p.m.; the approval therefore appears to be before binding. The policy identifier is consistent across the submission, workflow, approval, and bind record.
Step 4: Assess the evidence and conclusion. The records support that this transaction exceeded the threshold, was referred to an apparently authorized senior underwriter, and was approved before binding. Confirming that the authority roster was effective on the relevant dates and that the workflow timestamps are dependable strengthens this conclusion. The interview with the underwriter can explain the process, but it is not a substitute for those records.
Common mistake avoided. Treating a referral entry dated March 16 as proof of approval would confuse referral with authorization. The separate March 17 approval record is needed to substantiate the required decision. This walkthrough supports a conclusion about P-8041 only; it does not show that every policy above the threshold was referred.
Interviews, System Records, and Manual Evidence
Interviews are valuable for locating control points and interpreting records. Ask the person performing the control to explain what information they review, how they decide whether an item is acceptable, what they do with exceptions, and what record remains. Then corroborate important claims with evidence that relates to the selected transaction. An interview may be the only practical source for understanding an undocumented judgment, but the resulting limitation should be explicit.
For system evidence, do not infer the meaning of a status code or event name from its label alone. Ask how the workflow behaves, whether users can bypass it, and whether the log records failed or reversed actions as well as completed ones. Check that the identity shown corresponds to the person, rather than a shared account, and that the timestamp reflects the relevant event. These are evidence questions; establishing the reliability of an IT environment more broadly may require separate work.
For manual controls, inspect the completed record and determine whether it shows what was reviewed, by whom, and when. A checkmark without a date, reviewer, or identifiable transaction may be weak evidence. If the control includes follow-up, such as resolving a mismatch, trace the issue through to the recorded disposition rather than stopping at evidence that it was noticed.
Worked Example: Claim Payment and a System Approval
Scenario. A hypothetical claims unit requires a supervisor's approval for any payment above $15,000. Claim C-2176 has a payment instruction for $18,400. The claim system shows a supervisor approval event at 9:12 a.m. on June 7, and the bank transmission record shows the payment file was released at 11:40 a.m. on June 7.
Method. First verify the approval trigger, then connect the system event to the payment instruction, test the approver and timing, and follow the instruction to its recorded release.
Step 1: Verify the trigger. The payment instruction is $18,400 and the threshold is $15,000. Since $18,400 exceeds $15,000, the supervisor approval control applies.
Step 2: Link the approval to the instruction. The workflow history identifies claim C-2176 and the $18,400 instruction in the approval event. This is stronger than a system screen showing an approval status without a claim number or payment amount.
Step 3: Check authority and sequence. The authority roster lists the approving user as a supervisor during June. The approval at 9:12 a.m. precedes release at 11:40 a.m. by 2 hours and 28 minutes. The sequence is consistent with approval before release.
Step 4: State what remains to be checked. Confirm that the system history is a complete record of workflow events and that the bank transmission record concerns this same payment instruction. If the system permits an administrator to enter an approval on another user's behalf, investigate how the recorded user identity should be interpreted.
Conclusion. Subject to those evidence-reliability checks, the traced records support that the required supervisor approval was recorded for this payment before file release. They do not establish that all high-value payments received approval.
Common mistake avoided. A status of “approved” alone does not establish that the correct payment was approved before release. The transaction linkage, approver authority, and event sequence are each necessary parts of the conclusion.
Worked Example: Monthly Reconciliation With an Unresolved Difference
Scenario. A hypothetical finance analyst prepares a monthly reconciliation between claim-system payments and the general ledger. The walkthrough follows one reconciliation for September. The signed checklist says “reviewed,” and the reconciliation identifies a $3,600 difference. An email from the reviewer asks the analyst to investigate it. No resolution record is available, and the ledger was closed on October 5.
Method. Separate evidence that a review started from evidence that the full control objective was achieved. Trace the identified difference to its disposition and compare the timing with the control's required deadline.
Step 1: Identify the control objective. For this hypothetical process, the control requires a reviewer to examine the reconciliation, investigate differences, and ensure material differences are resolved or appropriately escalated before close.
Step 2: Determine what the checklist supports. The signed checklist supports that a review was recorded, assuming it is linked to the September reconciliation and identifies the reviewer. It does not, by itself, show which items were examined or whether the $3,600 difference was resolved.
Step 3: Trace the exception. The email requesting investigation supports that the reviewer noticed the difference and directed follow-up. There is no available record showing the cause, adjustment, or escalation. Thus, the evidence does not substantiate resolution or escalation before the October 5 close.
Step 4: Conclude with precision. The available documents support that review activity occurred and that the difference was identified. They do not substantiate completion of the exception-resolution requirement by the stated deadline. The appropriate conclusion is limited to this evidence gap; the missing document alone does not prove that no investigation took place.
Common mistake avoided. Treating a signed checklist as proof that every reconciliation difference was resolved would overstate what the record demonstrates. The evidence must be followed through the control's required outcome.
Documenting a Walkthrough Conclusion
A useful workpaper should let another reviewer understand what was examined and why the conclusion follows. Record the control objective, transaction identifier, date or period, process steps traced, people interviewed, records inspected, and any observation or reperformance. Identify evidence by source and explain how it links to the transaction.
Separate facts from explanations and conclusions. For example, “the workflow history records approval at 9:12 a.m.” is an observed fact; “the supervisor approved before release” is a conclusion that depends on the event being linked to the instruction, the timestamp being reliable, and the approver being authorized. Note limitations rather than filling gaps with assumptions.
A walkthrough may reveal that the documented control is not implemented as described, that the process has an unanticipated handoff, or that evidence is not retained. Those observations can guide further assessment. They should not be relabeled as a definitive conclusion about the control's performance across a whole period on the basis of one traced transaction.
Check Your Understanding
For each original scenario, identify the evidence needed and state the narrowest supportable conclusion.
- A hypothetical policy with a $1.3 million limit is subject to a $1.0 million referral threshold. The workflow shows referral on April 4, but the only approval record is dated April 8; the bind record is dated April 6. What does the sequence support? (Answer: Referral occurred, but the available approval record is after binding; it does not substantiate approval before binding.)
- A claims payment is above its approval threshold. A system screen shows “approved,” but displays neither a claim number nor approver identity. Name two additional evidence attributes needed to substantiate the control for a specific transaction. (Answer: At minimum, transaction linkage such as the claim or payment identifier, and evidence of the approver's identity and authority; timing relative to release must also be established.)
- A process owner says that exceptions are always cleared before month-end. The walkthrough finds a dated exception report for one transaction but no disposition record. What can the report support, and what remains unsubstantiated? (Answer: It can support that the exception was recorded or identified, subject to linkage and reliability; its investigation, resolution, or escalation remains unsubstantiated.)
- A workflow log records approval for payment instruction Q-52 at 10:00 a.m. The bank file containing Q-52 was released at 9:30 a.m. What is the correct timing conclusion, assuming both timestamps are reliable and refer to the same date? (Answer: Approval was recorded 30 minutes after release, so the records do not support the required pre-release approval.)
- A reconciliation reviewer provides a detailed interview and a completed checklist for one month. The checklist identifies the reconciliation but not any differences or their resolution. What follow-up evidence would most directly address the gap, and what cannot be concluded from this one walkthrough? (Answer: Obtain transaction-linked records of the identified differences and their investigation, adjustment, or escalation; one walkthrough cannot establish that the control operated consistently for all months.)