The Invoice Isn't Late Because of Billing
By Nick Bryant, Co-Founder and CTO, SMB Investor Network
7 min read
In brief
Use a manual work audit to find where work stalls, who owns it and what the records show. Ask what a simpler handoff would change before adding a tool.
A messy handoff is often unclear responsibility, not a missing tool. A manual work audit is a conversation about where work stalls, who can move it forward and what the records actually show. Have it before asking software to carry a process your team understands three different ways.
Describe where the work stalls
An owner hears that scheduling is hard, billing is slow, or staff spend the day chasing updates. Those are frustrations, not causes. The work might be waiting for a decision, a customer, a missing detail, or someone with permission to act.
Describe the unfinished work in words the people doing it recognise. What was supposed to happen? What's waiting now? What does the delay mean for the customer or the next person? Stay close to the work instead of naming a software category.
A made-up example: a service job is finished, but the office can't send the invoice. The field employee thinks the office has everything. The office is waiting for confirmation that the customer approved some extra work. The owner sees an unsent invoice and decides the billing system needs replacing.
The invoice is where the problem shows up. The missing approval is where the work actually stopped. A new billing screen would leave the office still unsure what it can bill.
An invoice moves. Waiting days add up.
An invoice passes through billing, approval, customer accounts payable and payment recording. Illustrative waits of 2, 3, 5 and 10 days add to 20 days.0.0 / 20 days
Work completed → Billing
+2 days
Billing → Approver
+3 days
Approver → Customer AP
+5 days
Customer AP → Payment recorded
+10 days
Work is complete. Billing waits for the details needed to issue the invoice.
Source: Illustrative — four fictional handoffs and their waiting times, not a benchmark or measured customer result.
Figure data
| From | To | Days waiting |
|---|---|---|
| Work completed | Billing | 2 |
| Billing | Approver | 3 |
| Approver | Customer AP | 5 |
| Customer AP | Payment recorded | 10 |
| Work completed | Payment recorded | 20 in total |
Illustrative invoice.
Ask of any proposed tool: would it change what stops this work from moving? Staff may disagree about what happened, and their accounts matter. The person who says a task is simple may never see the incomplete requests that make it hard for someone else.
Questions to open the conversation:
- What is the customer or colleague waiting for?
- Where does the work sit while everyone thinks someone else has it?
- What information or decision would let it move?
- Which part needs judgment about the situation?
- What useful purpose does the current handoff serve?
The last one matters. An apparently duplicate check may catch a changed customer request. A phone call may clear up something a written request can't. Understand that before removing the check or replacing the call.
Once the team can describe what's blocking the work, what to automate first puts the technology decision in context.
Find the owner
Knowing who last touched a task doesn't tell you who owns finishing it. One person enters the information without authority to approve it. Another answers customer questions without knowing the office is waiting on their answer.
A process owner is responsible for the work reaching its result, and the people involved have to know who that is. A title on an org chart doesn't help if staff still have to guess who can settle an unclear request.
In a role-mapping example, a founder had been personally filling every leadership role the business needed. Drawing those roles out made the problem visible and raised the real questions: what could be handed off, and what had to exist first. Look at the work a role carries before assuming that adding a person will take it off the owner.
In a manual work audit, ask where responsibility sits now and whether that person has what they need. An employee may be willing to own a handoff but lack access to the records. Another may have access but still need the owner to approve any exception.
Back to the invoice. The office employee may know how to prepare it and have no authority to decide whether the extra work was approved. Telling them to "own billing" doesn't answer who settles the disputed scope. That decision needs discussing as well as the admin.
Questions:
- Who is expected to notice that the work has stopped?
- Who can answer the question holding it up?
- What can the person receiving the handoff decide without the owner?
- What responsibility is someone carrying informally because nobody else took it?
- What would staff need to understand before that responsibility could move?
Listen for work that disappears into phrases like "the office handles it" or "management approves it". Ask what they mean in this case. They may describe something that works, or hide expectations that don't match.
Don't treat a responsibility gap as an employee's failure. It may come from conflicting instructions, a role that changed, or an owner who still makes decisions after delegating them in name. Let staff explain what they think they were asked to do.
An AI chief of staff only belongs in this conversation once responsibility is clear. Ask who would interpret its output and stay responsible for the unfinished work.
Check what the records actually show
A record can confirm part of the story without explaining the handoff. A completed-job entry shows the work happened. It may say nothing about what the customer approved, whether the office got that approval, or why the invoice is still unsent.
Ask what the records can show before drawing a conclusion. A missing entry might mean something never happened. It might also mean it happened in a conversation nobody wrote down.
Financial records show the same limit: a buyer may want margins by product or service, but if the seller booked all revenue together, the records can't support that analysis. Wanting the answer doesn't make the detail exist. Handoff records work the same way. A status label can't tell you about a decision nobody recorded, however much you want an explanation for the delay.
In the invoice example, "job complete" might mean the employee finished the physical work. The office may read it as "ready to bill". Neither tells you whether the customer accepted the extra work. Ask the people involved what the record means before treating it as an instruction.
That's a data quality question: does the information fit the decision someone needs to make? A neat record can still lack the detail to answer it.
Questions:
- What does this record directly confirm?
- What are we assuming because it doesn't say?
- Do the people creating and reading the entry understand it differently?
- Where would we find an explanation for a changed request?
- What's still unknown after talking to everyone involved?
Keep unknowns in the problem description. "The approval isn't in the records we checked" is different from "the customer never approved it." The first describes a limit in the information; the second claims something happened.
Information that was never captured is a different problem from information staff can't find. Ask which one they hit. Easier access won't fix missing information, and asking staff to re-enter everything may duplicate work they already do.
Don't fill the gaps with a guess at what the business must be losing. Describe the consequence plainly: the office can't send the invoice, the customer is waiting, the owner has to investigate before work continues.
What would a simpler handoff change?
A simpler handoff should make the work easier to understand and keep its purpose. What would the sender and receiver know that they don't now? What would still need a conversation?
In the example, the team might discuss how the office learns whether changed work was approved. The fix could be a clearer existing note, an agreed owner for approvals, or technology aimed at an agreed information gap.
Ask what happens after the change. Would the receiver know the work was ready? Would they have enough context to act? Would they know whom to ask when a case is unusual?
Ask what the change would make harder. An entry that helps the office may be awkward for a field employee to fill in on the job. Removing a conversation may remove the place where changed requirements get explained. A simpler screen can still leave someone carrying extra work out of sight. Once the fix is live, measure whether it paid off instead of assuming lighter work meant real savings.
Checks before proposing a change:
- Can everyone involved describe what's waiting in similar words?
- Is it clear who resolves the open decision?
- Have staff explained what the current handoff is for?
- Do the records support the explanation, with the gaps stated?
- Can the team say what the change would make clearer?
- Has the person receiving the work said what they still need?
The conversation may end unfinished. An honest disagreement about responsibility, or a known gap in the records, gives the owner something concrete to clarify. Don't turn uncertainty into a software requirement before you understand it.
Write the problem so the team can recognise and correct it. For the example: "Finished service work is waiting to be billed because the office can't confirm approval for a changed request. Nobody clearly owns resolving that approval, and the job record doesn't show what the customer accepted."
That names the stalled work, the responsibility gap and the limit of the records, and leaves the fix open. Staff can challenge it without arguing for or against a purchase.
Take a one-paragraph problem statement like that to the people in the handoff and ask what it gets wrong.
Source notes
The role-mapping and financial-records observations are paraphrased from interviews; examples are our own.