What is the difference between approval and reconciliation in SoD design?

How approval and reconciliation differ in a segregation of duties model

Approval is a pre-transaction control. It checks whether the request should be allowed before money moves, a vendor gets paid, or a record changes. Reconciliation is a post-transaction control. It checks whether what actually happened matches the expected result, using evidence from the ledger, system logs, statements, or reports.

The distinction matters because the controls answer different questions. Approval asks, “Should this happen?” Reconciliation asks, “Did this happen correctly?” In SoD design, those questions should not sit with the same person because one control is preventive and the other is detective, and together they create independent challenge.

That separation is what gives SoD its value. If the same role can both approve and reconcile, a person can authorise a bad transaction and then conceal it after the fact. If those duties are split, reconciliation becomes a second line of evidence rather than a self-review exercise.

Where the control boundary usually sits

Approval normally belongs with the person who has business authority over the request but not operational custody of the outcome. Reconciliation normally belongs with someone who can independently compare source records and investigate discrepancies, but who does not control the original approval decision. That boundary is about independence, not job title.

In practice, the strongest SoD design is role-based and process-based at the same time. A manager may approve an expense, a finance or operations function may reconcile it, and a separate reviewer may oversee exceptions. The point is to avoid combining request origin, approval authority, and exception confirmation in one hand.

The control can be weakened by partial overlap. For example, a user might not post the transaction directly, but if they can influence the source data used in reconciliation, the check is no longer fully independent. Good design looks at the full path from request to posting to review, not just the obvious approval button.

What SoD gets right when approval and reconciliation are separated

Separated duties reduce both fraud risk and error persistence. Approval limits unauthorised initiation, while reconciliation catches duplicated entries, missing postings, altered amounts, timing mismatches, and other anomalies that approval alone cannot see. In audit terms, one control is about authorisation, the other is about completeness and accuracy.

A useful way to think about the pair is that approval creates an authorised exception to normal processing, while reconciliation tests whether the exception was executed as intended. That is why reconciliation should not be treated as a formality or a managerial sign-off. It is the independent verification layer that proves the control actually worked.

For teams building or reviewing SoD rules, the most relevant internal guide is the Segregation of Duties (SoD) Guide, which covers conflicting permissions, compensating controls, and how SoD extends to service accounts, bots, and AI agents.

Risk and Threat Considerations

When approval and reconciliation are not separated, the main failure mode is self-review. That can let an employee or system operator both permit a transaction and later validate it as correct, which weakens fraud detection and allows errors to compound across multiple cycles.

Failure mechanism: The same role can approve a request, influence the transaction record, and then reconcile against records that are incomplete, manipulated, or never independently checked.

Impact: Undetected fraud, misstated balances, duplicate payments, hidden override activity, and slower discovery of control failure can follow, especially where exceptions are high volume or financial materiality is high.

Practitioner Guidance

What to verify: Confirm that the approver cannot perform the reconciliation, alter the evidence used for reconciliation, or close the exception they helped create. If they can do any of those, the SoD boundary is too weak even if the workflow looks separated on paper.

Decision rule: If a control owner can both authorise and certify the same event stream, treat that as a compensating-control scenario and require stronger oversight, exception reporting, or an independent review layer. If the transaction is high value or high volume, do not rely on after-the-fact review alone.

Practitioner takeaway: Approval is about permission, reconciliation is about proof, and SoD only works when the proof belongs to someone who did not grant the permission.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between human IAM controls and NHI governance?