SEGREGATION OF DUTIES OF PARALLEL OCCURENCES

The Exponential Risk of “Quite Similar” Unified Processing Systems

In segregation of duties (SoD), one unified processing-system is already dangerous: a single person, team, or system controls all four core functions of a transaction. But the risk does not simply add up when an organization runs multiple parallel occurrences of that same unified pattern. When those occurrences are “quite similar,” the exposure behaves more like an exponential than a sum.

This article uses a math-metaphor to explain why: if one unified processing-system is a “quite similar equation,” then placing many of them in parallel is not just repeated addition. It is closer to raising a risky base to a power.

1. What Is a “Unified Processing-System”?

A unified processing-system exists when the following four duties are collapsed into the same person, team, or tightly coupled system:

1. Authorization / Approval — deciding that a transaction may proceed.
2. Recording (bookkeeping) — entering the transaction into the books or system.
3. Custody of assets — physically or logically holding cash, inventory, data, or other assets.
4. Reconciliation — comparing recorded assets to actual assets and explaining differences.

When all four sit inside one unified processing-system, there is no independent check. The same entity can initiate, hide, hold, and “reconcile” the result.

2. The Example: Multiple Unified Systems Running in Parallel

Imagine five branch offices. Each branch has a supervisor who:

• approves refunds and adjustments,
• posts the related journal entries,
• holds access to the cash or inventory, and
• performs the monthly reconciliation.

Each branch is a unified processing-system. The five branches are parallel occurrences. They look “quite similar” because they use the same template, same policy, same spreadsheet, same ERP role design, and same supervisory logic.

That similarity is the problem. If the design is flawed in one branch, it is probably flawed in all five. If one supervisor can conceal a discrepancy, the same method likely works in the other four. The organization does not merely have five separate control weaknesses; it has five copies of the same control weakness running side by side.

3. The Math-Metaphor: Exponential of a “Quite Similar” Equation

Let one unified processing-system be U, where:

U = Authorization + Recording + Custody + Reconciliation

If there are n parallel occurrences, and each is “quite similar,” then:

U₁ ≈ U₂ ≈ U₃ ≈ … ≈ Uₙ

The risk is not best pictured as U + U + U. It is better pictured as a base risk raised to an exponent: Uⁿ — because each similar instance multiplies the chance that the same blind spot is replicated, repeated, and concealed.

This is a metaphor, not a literal accounting formula. A more practical illustration is:

Exposure ≈ 1 − (1 − p)ⁿ

Here, p is the chance that one unified processing-system fails or is abused, and n is the number of parallel occurrences. As n grows, exposure rises quickly. Worse, when the systems are “quite similar,” p itself may be higher because the same design flaw exists everywhere.

4. Why the Risk Is Exponential-Like, Not Merely Additive

• Replication of blind spots: A “quite similar” system copies both good controls and bad controls. One gap becomes many gaps.
• Concealment across occurrences: A person or team controlling multiple parallel occurrences can move a discrepancy from one instance to another and “reconcile” it away.
• Systemic error propagation: A flawed formula, role design, or approval rule in one template can spread across every parallel occurrence.
• Loss of independent reconciliation: If the same unified system records and reconciles, the check is no longer independent — and repeating the pattern does not create independence.

5. Control Strategies: Break the Similarity, Split the Duties

• De-unify each occurrence: Separate authorization, recording, custody, and reconciliation across different people or systems in every parallel instance.
• Use dual authorization: Require more than one approver for sensitive transactions, especially where parallel occurrences share the same design.
• Apply SoD rules across all instances: In ERP environments, enforce the same conflict rules in development, test, and production — and across every branch or entity.
• Make reconciliation independent: The person who records or holds custody must not perform the reconciliation. Use a different person, team, or automated control.
• Monitor across parallel occurrences: Look for the same anomaly appearing in multiple “quite similar” systems. That pattern is the exponential signal.
• Introduce deliberate differences where risk is high: Not every process must be identical. Vary approvers, access rights, and reconciliation owners so that one copied flaw does not become a system-wide exposure.

In summary, a unified processing-system that combines authorization, recording, custody, and reconciliation is risky on its own. But when many “quite similar” versions run in parallel, the risk behaves like an exponential of a repeated equation: the same weakness is copied, multiplied, and given more places to hide. Strong SoD breaks the similarity and separates the four duties in every occurrence — not just in one.