Accounts receivable automation that stops chasing the moment a customer pays

The CRM should be where the decision to bill is made, because that is where the people who know the work is done already are. It should not hold the balance. A CRM column that says Paid is a copy, and copies go stale; the ledger is the record of what is owed, and the CRM reads it.

Lines are where CRM-to-ledger invoicing usually goes wrong. An order with five products, two tax treatments and a delivery charge is five or more invoice lines, each with its own item code, account and tax code, not one line with a total. Collapsing it to a single line is quicker to build and wrong for reporting, sales tax or VAT, and any later credit note against one item.

The closest published example is a set of Make flows for a vocational training provider. When a student's billing status in monday.com changes to the label for a recurring, enrolment or upfront fee, a scenario finds the contact in Xero, creates an authorised invoice due in seven days with a line built from the CRM's price, item code and description and a revenue tracking category, sends it through Xero's own email, and writes Waiting Payment, the invoice number, the issue date and the online link back onto the CRM item. Three more scenarios were built to chase: a friendly reminder before the due date, a firmer one once overdue and a sales-toned chaser for the upfront fee. Make's counters show 78 runs across the six scenarios with one error, a duplicate contact name.

Its published limits are the reason this page reads the way it does. Creating an invoice is not idempotent, so selecting the trigger label again raises a second one. Nothing writes Paid or Overdue back to the CRM. The recurring-fee scenario matches the contact by name with no fallback, so a contact it does not know is skipped. The reminders have no cool-downs, read lists capped at twenty-five items and are switched off. Those are the failure modes in the next sections, observed rather than imagined.

Two more flows, for a trailer manufacturer, cover the other end and the start. One watches Xero every fifteen minutes in business hours for invoices with nothing left to pay, which catches full payment whether it arrived at once or in several parts, and then raises a release form once, updating it rather than creating a second. Its error history includes thirteen failures from Xero's rate limit on one morning when a backlog was released at once, after which runs were processed one at a time with retries. The other matches quotes and invoices back to the website enquiry that started them, by email alone, so a customer billed through a company accounts mailbox is not linked.

The two custom systems are receivables inside their own books. On the school group's ERP, students, fee invoices, payments, expenses and payslips feed one accounting layer, money functions post an invoice, a payment and its ledger entry together, and fee reminders go out over WhatsApp from templates, so chasing became a scheduled action with a record instead of a notebook. On the trading group's ERP, invoices move from draft through approval to unpaid, partial and paid, and anything not yet approved is kept out of revenue and outstanding totals.

Beyond what is published, we have built accounting workflows and integrations for other clients, including a Zapier build that takes WordPress and WooCommerce orders into monday.com and then into Xero invoices with each order line carried as its own invoice line. That rests on our own account of the work; there is no case study for it. One of our published client reviews, from the director of Divine Kitchens, was left for work across monday.com, Xero, WordPress and Buildxact; the review speaks to attention to detail, not to a receivables result.

Be fair to the ledgers first. Both have built-in reminders, and for a business that raises invoices in the ledger and sends them from it, those features may be all the automation receivables needs.

The QuickBooks condition is the one people miss: its reminders only fire for invoices that QuickBooks itself emailed, so a flow that sends invoices from the CRM or your own mail account gets no reminders from QuickBooks at all. Xero's reminders are for invoices still awaiting payment, which in practice means awaiting payment in Xero: a payment not yet recorded there does not stop them.

The built-in features stop being enough when the reminder has to know something the ledger does not: that the customer has an open dispute logged in the CRM, that a site visit is booked to fix the snag they are withholding payment over, that the account manager wants to call first, or that a reminder should go by SMS or WhatsApp rather than email. They also stop when the invoice should not have been typed into the ledger in the first place, because the CRM or the shop already had every line.

This page covers the customer side: from the event that makes an invoice due to the cash being applied, with reminders, credit notes and disputes. Three other pages sit next to it, and each links back here.

• Accounts payable automation is the mirror image, for supplier bills: capture, matching to purchase orders, approval limits, bank-detail change controls and the payment run. Its risk is paying the wrong account; ours is chasing the wrong customer.
• Finance workflow automation covers approvals and reconciliation across finance generally, including approvals that gate the totals and an honest note on month-end.
• CRM automation covers the CRM itself: pipelines, stages and the follow-ups that happen before anything is billable.

Most of our projects land between $5,000 and $10,000 (US dollars); larger systems cost more. That is a typical range, not a quote, and no case study above states a price, so it is not attributed to one. A flow that raises invoices from one CRM status into one Xero organisation sits at the small end, and it can be smaller still on Make or Zapier if your rules are simple. What moves it up:

• How many invoice types there are (deposits, stages, recurring fees, one-offs) and how each is triggered.
• Mixed tax on lines, more than one currency, or more than one ledger organisation.
• Whether reminders need to read anything outside the ledger, such as disputes, account holds or channels other than email.
• Whether payments have to be written back to the CRM, and how part payments, credit notes and refunds should look there.
• Whether the rules need a database underneath: a guarantee that an invoice is raised only once, and a record of every reminder kept longer than a platform's run history.

If you raise invoices in Xero or QuickBooks, send them from there, and your reminders do not depend on anything the ledger cannot see, turn on the built-in reminders and stop. Building next to them creates a second schedule that can disagree with the first. The same goes for a dedicated credit-control product that already reads your ledger and does what you need. Building is justified when the invoice should be raised from somewhere else (a CRM, a job system, a shop), when chasing has to respect information that lives outside the ledger, or when the payment needs to flow back to the people who do the work.

Some things stay manual on purpose. Credit control is judgement: whether to call, whom to call, when to put an account on hold and when to accept a payment plan. Disputes, write-offs, refunds and anything involving collections or legal action are a person's decision every time. We also do not do the accounting. Revenue recognition, tax treatment and how your books handle bad debt stay with your accountant, and we will not claim compliance work we cannot evidence.

It is also the wrong answer at low volume, where someone raising a dozen invoices a month by hand costs less than maintaining a flow, and wherever nobody will own the exceptions: the unmatched contact, the failed write, the bank line that covers three invoices. A queue of those that nobody reads is worse than no automation, because the invoices stop being raised quietly.