Quote accepted, invoice raised, payment chased

Where does the cashflow loop actually break?

It breaks in three specific places, and none of them is the invoice itself.

Acceptance is invisible. A client replies "happy to proceed" in an email thread. Nothing in any system knows that. The job starts because a person read the email, and the invoice depends on the same person remembering later.

Invoicing waits on delivery finishing and a person being free. In a busy month those two conditions do not overlap for weeks. Every week between delivery and invoice is a week of your working capital funding someone else's business, and it is entirely self-inflicted.

Chasing depends on someone opening the aged receivables report. Which happens when cash gets tight, which is precisely when the follow-up should already have been running for a month. The invoices that go unchased longest are usually from the busiest periods, when the firm could least afford to notice.

There is a fourth, subtler leak. Because the loop is manual, nobody has clean data on it. Ask a firm in this state how long it takes from acceptance to invoice, or from invoice to payment, and you will get an anecdote instead of a number.

What does the loop look like when it works?

Every step is triggered by the step before it, and the only human decision is whether the invoice is correct.

1. Acceptance becomes an event. An accept button on the quote, an e-signature tool, or at minimum a status field someone sets deliberately. Anything that turns "they said yes" into a state change a system can read.
2. The job or project is created with the quote's details attached, so the team is working from the same record the invoice will be built from.
3. A draft invoice is created in the accounting system using the quote's line items, the client's existing contact record, and the payment terms already agreed. No retyping, which means no transcription errors and no argument about what was quoted.
4. A person approves it. They are checking one thing: does this match what we agreed and what we delivered. That takes seconds when the draft is built from the quote.
5. The invoice sends with a payment link where you have an online payment service connected, because the easiest way to be paid sooner is to remove steps for the payer.
6. The reminder sequence is scheduled at that moment. Not created later, not dependent on anyone noticing. The schedule exists the instant the invoice does.
7. Payment closes the loop. The accounting system knows when the invoice is paid, so the workflow cancels the remaining reminders, marks the job complete and stops. Nothing embarrasses a firm faster than chasing money it has already banked.
8. The numbers are captured. Acceptance to invoice, invoice to payment, per client. After a quarter you can see which clients are slow and which service lines take longest to bill.

In Australian practice this usually sits on top of Xero or MYOB, and both allow another system to create an invoice and read whether it has been paid. Before building anything, check what your existing product and plan already do: both have some built-in reminder capability, and a feature you already pay for is always the cheaper answer.

Should an invoice go out without a human seeing it?

Not until the drafts have been right for long enough that you would bet on them. Money and clients are the two things worth being conservative about, and the cost of a human glance at an invoice is trivial compared to the cost of a wrong one.

The sensible progression is to earn the trust one category at a time. Standard, repeating work with fixed line items can go unattended fairly quickly. Variable work, anything with a change order, and anything where the scope shifted during delivery should keep a person in the loop indefinitely, because those are exactly the invoices clients query.

The same logic applies to the reminders. The first two can be automatic and impersonal. The point where a reminder becomes a phone call from a person should be a decision someone makes with the relationship in mind, not a rule that fires on a day count.

How do you chase payment without damaging the relationship?

Make the sequence short, polite and predictable, and give it clear stop conditions. Most of the damage from automated chasing comes not from the reminders themselves but from reminders that keep arriving after the situation has changed.

The rules worth building in:

• Stop on payment. Obvious, and the most common failure. If the workflow reads payment status from the accounting system rather than a separate list, this takes care of itself.
• Stop on reply. If the client responds to a reminder, the sequence pauses and a person picks it up. An automated third reminder after a client has explained a delay reads as contempt.
• Stop on dispute. If the invoice is queried, chasing it is the wrong response. Route it to whoever can resolve it.
• One voice. Reminders should come from the same address and identity the client already deals with, not from a no-reply account.
• Escalate by changing who sends, not by changing the tone. A short note from the principal is more effective, and less corrosive, than an increasingly stern automated email.
• Never chase the wrong thing. If the invoice has an error, the reminder is a demand to pay for a mistake. This is the strongest argument for keeping human approval on non-standard invoices.

What do you need in place before you build it?

The prerequisites are unglamorous and they determine whether the build works. Get these right and the automation is straightforward. Skip them and you will automate an argument.

• Payment terms in writing on every quote, so the reminder schedule has something to key off.
• A tidy chart of items and tax treatment in your accounting file, so the workflow never has to decide how something should be coded.
• One system of record for the money. The accounting file is the ledger. Do not build a parallel spreadsheet of who owes what, because the two will disagree and everyone will believe the wrong one.
• Correct billing contacts, separate from the day-to-day contact, because in many client organisations they are different people and reminders sent to the wrong one go nowhere.
• A defined moment of delivery. If nobody marks work as delivered, nothing can trigger.

Where does AI genuinely earn its place here?

In the language, not the logic. Creating an invoice from a quote is arithmetic and mapping, and it should be handled by plain integration where the behaviour is exact and predictable every time.

Where a model does earn its keep is reading an inbound email and recognising that it constitutes acceptance, classifying replies to reminders into paid, promised, querying or gone quiet, summarising a long thread so the person making the call has the history in three lines, and drafting the scope description for a client who wants more detail than the line item carries. All of those are language tasks with a human reading the result. None of them should be trusted to move money on their own.

What to do next

Measure the loop before you change it. For the last twenty jobs, note the date the client accepted, the date the invoice was raised and the date it was paid. That takes an hour and it will tell you whether your problem is the invoicing gap or the collection gap, which are different builds with different returns.

Then fix the cheapest thing first: get payment terms onto every quote, turn on whatever reminder feature your accounting platform already includes, and see what is left. What remains is usually one workflow, and it is the one Shift builds most often for agencies and consultancies.