“Closed” is a bold status for a transaction that still needs permission to be paid.
The sale closed. The paperwork arrived. The task landed in accounting.
Everyone moved on.
Except the person sending the money, who still needs approval.
The notification works. The integration works. The task appears exactly where it should.
The approval is in somebody’s email.
One label. Three different meanings.
Sales uses Closed to count the deal. Operations uses it to finish the paperwork. Accounting is expected to treat it as permission to release funds.
Open the task and there’s an amount, a recipient, and a due date. What’s missing is the answer to a fairly important question: who approved this payment?
Someone may have approved the deal without approving the payout. The contract may be signed while a commission calculation is still under review. A revised amount may be sitting in a message that never reached the person paying.
“Closed” has been asked to do quite a lot of work.
It hasn’t supplied the supporting records.
What is the task asking someone to do?
Review a calculation, collect missing information, request approval, and release payment are separate actions.
A task called “Pay commission” gives the person assigned a different instruction from “Review commission calculation.” If the amount is still unconfirmed, the second description is closer to the work actually waiting.
Before release, accounting needs the payee, the amount, the basis for that amount, the relevant company, and authorization under the business’s process.
Where approval is required, the record should identify who gave it and what they approved. A later change to the amount deserves another look.
The next person shouldn’t have to interpret enthusiasm in a sales email as payment authorization.
What I’m carrying into BrokenBooks
Building BrokenBooks around the accounting engagement keeps bringing me back to these transitions.
A finding becomes proposed work. A proposal becomes an engagement. A task reaches review. A request receives an answer.
At each point, the status needs to describe what has actually happened and what still needs someone’s attention.
For the cleanup workflow, that means preserving the context behind the work as it moves forward. A task marked complete should have a meaning the reviewer can understand.
The payment example is a design principle I bring to that work. It isn’t a claim that BrokenBooks currently runs a business’s payout approvals.
Read the handoff from the receiving end
Look at the task as the person expected to act on it.
Can they identify the supporting record? Do they know what is settled and what remains open? Is their next action clear?
If they still need to ask whether they’re allowed to pay, the handoff has reached accounting before the decision has.
BrokenBooks is in private-beta testing, with workflow development and validation continuing. You can follow the product’s development here.
A task appearing on time is useful.
Otherwise, congratulations.
We automated the arrival of another unanswered question.
