Eight handoffs carry approved time to a delivered invoice. Each one needs an owner, a readiness rule, an exception path, and a next decision.
A time entry can be approved, billable, inside the billing period, correctly rated, and still belong on a different invoice. And the few times that happen, you have both your own teams and customers upset. There are clearly ways to fix that - here's one. I must warn you: this will sound mundane and painful (even writing it was some of that), but it is critical to get right, so your company can get paid in time.
The typical path from submitted time to a sent invoice contains eight handoffs. Each handoff needs an owner, an input record, a readiness rule, an exception path, and a next decision. Leave one of those unnamed and Finance needs a detective, customers need pacifying.
The eight handoffs are:
And across all eight, there needs to be complete traceability. Every handoff should retain its source, owner, decision, exception, status, and next destination.
Let's look at how we can make that happen, in more detail.
Start with a visible cutoff. The cutoff tells contributors which work belongs in the billing cycle and when their entries must be complete. "Complete" needs a practical definition. A complete entry usually identifies the person, project, task or activity, date, duration, and a useful note. The exact fields depend on your organization. The important part is that contributors and reviewers share the same definition, so deadlines don't bring arguments.
The owner of this handoff is usually the person or team running time collection. The input to this step is submitted time. The readiness rule states that expected entries have arrived and contain the required information. Missing or incomplete entries should follow a named correction route.
This is where our previous article on keeping time tracking out of Friday night leaves the process: submitted work is visible, specific exceptions have been identified, and the review can begin.
Find exact exceptions before asking anyone to "check their time." A useful exception names the entry, the problem, the owner, and the required correction. For example, Jordan records workshop and implementation time for one customer across two projects. One of those entries has no useful description. And another points to the wrong project. So the correction request should identify those two records. A general reminder without that detail will make Jordan reread the week and wonder why Finance is so offended.
The corrected record returns through the same review path. Keep the original issue and correction history attached. That history explains why the record changed and who changed it. So the handoff is ready when every material exception has been corrected, accepted under a documented rule, or held outside the current cycle.
Time approval confirms that the work record meets your organization's review rules, it does not authorize an invoice yet. A manager may check project, task, hours, note, date, and any policy exception. The manager then approves the record or returns it with a reason. Approved time should move into a controlled state so casual edits cannot change the input after review. That protection is significantly valuable downstream. Finance needs to know that the hours it receives match the hours the manager approved. Corrections can still happen, but they should reopen the appropriate review rather than quietly rewriting data.
The output of this stage is dependable approved time. The time-approval process can make that review repeatable. Billing eligibility still depends on later rules.
Most organizations already have a standard billing process. They do not need to define it again every month. So opening a scheduled billing cycle means running the standing process for a specific period. A monthly organization might open the April cycle after April time closes. A weekly organization selects the relevant week. The schedule, owners, approval rules, billing terms, and exception routes should already exist. So an existing cycle record establishes the actual date range and execution. It also gives the work a shared reference point. People can discuss "the April billing cycle" without comparing three spreadsheets named Final, Final-2, and Final-Use-This-One.
Changes to the standing policy belong in a controlled policy update, while changes to this particular cycle belong in the cycle record.
Approved time becomes eligible work after it passes the billing-cycle rules. A basic eligibility check in the process asks whether each record is approved, is inside the selected period, is billable under the agreement, and is not already invoiced. The process should also apply documented exclusions and holds. For example, an approved internal activity can remain non-billable, while a customer dispute can hold an otherwise valid line and a prior invoice may already contain the work.
Next, group the eligible records using the organization's invoice rules. Company, project, contract, currency, purchase order, or billing contact may affect the grouping. Jordan's entries split into two invoice candidates when the customer requires separate project invoices. Remember: an invoice candidate is a proposed collection of eligible work, still waiting for billing context and review.
Apply relevant customer and project rules to each candidate. These rules can include rates, billing terms, fixed-fee treatment, exclusions, holds, taxes, currency, descriptions, purchase-order requirements and invoice grouping. Then prepare a reviewable draft. The draft should keep its source entries visible and show how each amount was produced. Finance should be able to inspect the customer, project, hours, descriptions, rates, exceptions, totals and current status. And handle exceptions. Exceptions need decisions before the draft advances. Jordan's workshop line may have no confirmed rate. Another line may be held under the customer agreement. Route the rate question to its owner and keep the held line out of the invoice. Record both decisions with the draft.
This is a good place for governed automation. A repeatable process can gather eligible work, apply configured rules, assemble the draft, and surface exceptions. Human owners still make the decisions the rules cannot settle. As an example, the video below shows this stage running as an Eos Agent, and the approval checkpoints it stops at before anything is sent. But this article itself remains a process you can use with any suitable system.
Invoice approval is a distinct gate. Draft preparation provides the material for the decision and Approval authorizes the invoice to move toward finalization and delivery. The approver should see the draft, source records, resolved exceptions, open holds, delivery details, and any relevant supporting documents. The approval should also confirm the customer entity, currency, payment terms, tax treatment, total, and destination. At this stage, if a material issue remains, return the invoice for correction, back to the previous stage (retain the reason with the draft). The revised invoice should come back through approval, especially when the correction changes the customer, amount, terms, or supporting evidence. And the approved record should identify who approved it and when. It should also state exactly what was approved.
The process finishes when the approved invoice reaches the customer through an agreed channel and the delivery result is recorded. The delivery route may be a configured billing system, an accounting platform, an email with/out a PDF, a customer portal or an external process. Some customers may still require physical mail. Your organization should define the supported channel, destination, sender, attachments, and proof of delivery.
Finalization and delivery remain controlled actions. Your system should prevent an unapproved draft from being sent. It should also retain the final invoice identifier, version, delivery time, destination, method, and outcome. Record external delivery in the operating system when someone sends the invoice elsewhere. And finally, a delivery failure needs an owner and a retry path. A bounced email, rejected portal upload, or missing address should reopen delivery without reopening the approved commercial terms. Reopen approval only when the invoice itself changes.
Choose one completed invoice and trace it backwards. Write down the following five fields for each of the eight handoffs:
Look for missing owners, undocumented rules, decisions made outside the record, and delivery outcomes that nobody captured. Those are typical gaps where routine billing turns into a post-delivery exercise.
Our goal here is a process that carries dependable time into an approved invoice and carries that invoice all the way to the customer. With traceability, someone in your org can follow the work from beginning to end, leaving Finance with a process that just runs.
To map one anonymized billing cycle with Eos, schedule a 20-minute time-to-invoice review.
This walkthrough shows the same process running as a governed Agent: the instruction written in plain English, the plan Eos compiles from it, the three approval checkpoints it declares before it runs, and the run stopping at the first one to wait for a person. The screens come from the Eos demo organization.
Bring one anonymized billing cycle, its cutoff, approval path, and one recurring exception.