The Approval That Needs No Pad
The most common request we turn down about signatures is a pad on the approval screen. Adding one there would not strengthen the control — it would disguise a strong control as a ceremonial one.
When we shipped signature capture, the first follow-up request was predictable: put it on expense approvals. Then budget sign-off, then procurement authorisation. The reasoning is intuitive and it is wrong, and the reason it is wrong is worth more than the feature would have been.
Compare the two records honestly
Put the two kinds of evidence side by side and ask which one you would rather hold in an argument.
An in-app approval
- Made by an authenticated account — somebody signed in, through your login controls.
- Gated on a permission that had to be granted deliberately.
- Written to the audit trail with the actor, the moment and what changed.
- Attached to the record it decided, not to a piece of paper about it.
- Cannot be produced by anyone who was not logged in as that person.
A drawing on the same screen
- Made by whoever was holding the mouse.
- Illegible by nature, so it names nobody without a typed name beside it.
- Verifiable against nothing — there is no specimen signature to compare it to.
- Adds a step that feels like rigour and supplies none.
- Can be drawn by the same logged-in person in either case, so it distinguishes nothing.
The approval is the stronger record on every line that matters. It is tied to an identity your access controls maintain, it required a permission somebody granted, and it is written to a log that also records what the decision changed. The drawing adds no fact that the approval did not already carry.
A control that looks more serious than it is has been made worse, not better.
Why adding the pad is actively harmful
This is the part that took us longest to articulate, and it is not a performance argument about extra clicks.
A drawn mark carries cultural weight. People treat a signed page as more binding than a clicked button, whatever the technical reality. So putting a pad on an approval screen teaches everyone — your own staff, your auditors, the person reviewing the process next year — that the drawing is where the authority lives. It moves the perceived control away from the mechanism that is actually enforcing something and onto the one that is not.
Then somebody eventually notices that the drawing proves nothing, and the reasonable conclusion they reach is that the approval was theatre. It was not. The approval was real, and the pad is what made it look otherwise.
The test we actually apply
One question decides it: is there a person physically standing there, and is something changing hands?
Where a pad belongs, and where it stops belonging
Goods received at the gate
Somebody hands you a delivery and walks away. Sign it — you may never see the driver again, and the count is disputed later.
Stock issued to a fitter
Material leaves the store with a named person who denies it three weeks later. Sign it.
Asset handed to a custodian
A laptop changes hands, with condition recorded at both ends. Sign it.
Transfer dispatch and receipt
Two of your own sites, two honest counts, one quantity. Sign both ends.
Vendor acknowledging a purchase order
A real signature is wanted, but the signer is a company at a distance. This is a document sent, tracked and returned — remote e-signature, not a pad.
Expense approval
A decision by an identified account against a permission, logged. Nothing is changing hands and nobody is present. No pad.
Budget sign-off
Same shape, higher stakes, same answer. The permission is the control.
The middle of this line is where most software gets confused, because "we need a signature" is said about both ends and means two different mechanisms.
What is actually enforcing your procurement controls
Since we are being precise about where the control lives, it is worth being precise about what our own approvals do and do not do — because this is the answer to press us on, not to accept.
Approving a procurement request is gated on who holds the approval permission. There is no value band that routes a request above some figure to a committee and one below it to a line manager. If your procurement manual is written that way, the routing remains a matter of who you grant the permission to and of your own discipline, rather than something the system enforces on your behalf.
What the system does refuse, by itself and by default, sits downstream of the approval: a delivery larger than the order is blocked at receiving, a payment that does not match its order and receipt is blocked unless somebody with a specific permission overrides it in writing, and a stock adjustment above a value you configure needs a second person. Those are the real refusals. A drawing on the approval screen would add nothing to any of them.
If a policy demands a signature on an approval
Some donor and public-sector rules genuinely require a signed authorisation document, and that is a real requirement rather than a misunderstanding. It is also not a pad problem: what is wanted is a document, produced, signed and retained. Send it for remote signature and file it. Do not simulate it with a squiggle drawn on an internal screen by somebody who was already logged in.
The one place we changed our own minds
The test cuts against us as well. Stock counts looked like an obvious candidate — there is a status, a blind count, variance rules, and a person doing the counting. We ranked it lower than it appears and did not build it, because the count already carries audit events and an authenticated counter, which is stronger evidence than a mark. Signing there would be ceremony by our own definition.
The place the test genuinely favours a pad and we have not built one yet is a technician closing a job at a customer site — somebody physically present, and something being handed over in the form of completed work. That is a real gap rather than a refusal, and the distinction between the two is the whole point of this post.
What AWRA OpsHub does today
- Handover signatures on goods receipts (including against a purchase order), stock issues, asset custody movements, and both ends of a stock transfer.
- Approvals recorded as authenticated, permission-gated decisions written to the audit trail.
- Downstream refusals that do not depend on anyone signing: over-delivery blocked at receiving, mismatched payment blocked without a written override, and high-value adjustments requiring a second person.
What it does not do
- No signature pad on expense, budget or procurement approvals — declined on the reasoning above rather than pending.
- No value-banded approval routing. Approval is gated on the permission, not on the amount.
- No signature on inventory count sessions; the count's own audit events are the stronger record.
- No signature yet on a field job completed at a customer site. That one passes the test and is a genuine gap.
Not ours, by choice
- Signed authorisation documents required by a donor or statute are a document workflow, not a pad. Use remote e-signature and retain the file.
If you disagree with the refusal, the argument to make is that somebody is physically present and something is changing hands. That is the test, and we will apply it to our own list as readily as to a request.
What is not built today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for the gap you just read about. Two honest qualifications so this is worth what it claims: a handful of gaps on this blog are deliberate refusals rather than missing work — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words rather than calling it a gap. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped gaps, which are the ones this blog admits most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsOur take
Put a signature where a person is standing in front of you and something is leaving your hands. Everywhere else, the stronger evidence is the one you already have: a named account, a permission that had to be granted, and a log of what changed. Adding a drawing to that does not raise the ceiling — it lowers how seriously anybody takes the floor.
This is the third of three posts on handover signatures. The Squiggle Is Not The Evidence covers what a captured mark actually consists of, and A Hundred Out, Ninety-Seven In covers why a stock transfer needs two of them.
Frequently asked questions
Why will AWRA not put a signature pad on expense or budget approvals?
Because the approval is already the stronger record. It is made by an authenticated account, gated on a permission that had to be granted, and written to the audit trail with the actor and the moment. A drawing adds no fact the approval did not carry, and it shifts the perceived authority onto the weaker mechanism — which makes a real control look ceremonial.
How does AWRA decide where a signature belongs?
One test: is a person physically present, and is something changing hands? Deliveries, stock issues, asset handovers and both ends of a stock transfer pass it. Approvals and sign-offs do not, because nothing is changing hands and the decision is already tied to an identified account.
Are AWRA procurement approvals routed by value?
No, and this is worth pressing us on. Approval is gated on who holds the approval permission; there is no value band that sends a large request to a committee and a small one to a line manager. What the system does refuse on its own sits downstream: over-delivery blocked at receiving, mismatched payments blocked without a written override, and high-value stock adjustments requiring a second person.
Our donor rules require a signed authorisation. What do we do?
Treat it as a document workflow rather than a pad. Produce the authorisation document, send it for remote signature through the e-signature connector, and retain the signed file. Simulating it with a drawing made on an internal screen by an already logged-in user satisfies the letter of nothing.
Will you ever add signatures elsewhere?
Where the test is passed, yes. A technician closing a job at a customer site is somebody physically present handing over completed work, and that is a genuine gap rather than a refusal. Inventory count sessions are a refusal: the count already carries its own audit events and an authenticated counter.
