The signature that checks nothing

The problem it solves

There is a signature in the corner of nearly every document that leaves a company. Most of those signatures check nothing, and the person signing knows it: nobody ever explained what they are supposed to find, what they should be comparing the document against, or what to do when something does not add up.

The control started for a concrete reason, a duplicate payment, an order nobody authorized, a client billed for less than the job, and that reason was lost over time and with the people who left. What remained was the gesture. Signing happens fast, in volume, sometimes in advance so as not to slow anyone down, and the work carries on.

The whole problem arrives on the day an error passes three approvals and leaves the building. That is when it becomes clear the organization had controls but no checking, that it had been paying the cost of the delay for years without collecting the protection, and that the conversation about accountability is now impossible because everyone signed and nobody looked.

What it covers

The session opens with the question almost nobody puts to a control: which specific error is this meant to prevent. Participants bring the controls that exist in their operation today, approvals, reconciliations, two-signature reviews, receiving checks, and put each one through that question. The ones with no clear answer get marked, and that group is usually larger than anyone expected.

Placement comes next. The same control is worth a different amount depending on where it sits: checking before the order ships costs a few minutes, checking afterwards costs a call to the client, a credit note and an awkward conversation. Through scenario analysis, the group moves controls along a process and watches the cost of the error change at each position.

The third stretch is drafting. Writing a control so the person performing it knows what to look for, what to compare it against, and what to do when a difference turns up. Participants rework their own controls on a worksheet, and the group debates the balance between what is worth automating and what needs human judgement, which is not the same in a high-volume operation as in one built on large, infrequent transactions.

The workshop closes on the two matters that decide whether a control system survives. Exceptions, which always exist and need a named authorizer and a place where they are recorded. And what the company does the first time a control catches something real, which is when the team learns whether any of this was serious. The opposite decision gets airtime too, the one almost never made deliberately: which errors are not worth controlling.

What participants learn

• Identify the specific error each existing control is meant to prevent.
• Analyze which of those controls are performed on paper only.
• Design the placement of the check at the point in the process where the error is still cheap.
• Develop the wording of a control that states what to look for, what to compare and what to do about a difference.
• Evaluate which errors are not worth controlling because the control costs more than the error.

Agenda

1. 01Which error does this control prevent, the question rarely asked
2. 02Approvals that check nothing
3. 03Where the check belongs inside the process
4. 04Errors that surface by themselves and errors that leave the building
5. 05What a control costs against what the error costs
6. 06Exceptions: who authorizes them and where they are recorded
7. 07Automated checks, human checks, and the balance between them
8. 08What to do the first time a control catches something

What the organization leaves with

• An inventory of live controls with the error each one prevents, or a mark showing it prevents none.
• Two or three of the company's own controls rewritten to state what to look for and what to do about a difference.
• A written exceptions rule: who authorizes them and where they are recorded.
• A list of controls the company decides to retire, with the reason noted beside each.