How to Get Law Firm Invoices Paid: Fix the Invoice, Not the Chasing

When a firm looks at its aged receivables, the instinct is to treat the problem as behavioural: clients who do not pay, and a firm that does not chase hard enough. Sometimes that is right. More often the delay traces back to the document itself.

An invoice that does not say what the work was, that arrives without the reference the client's accounts payable system requires, that taxes a disbursement it should not have taxed, or that reaches one person at the client who is not the person who pays — none of these get refused. They get set aside, and a set-aside invoice ages exactly like a disputed one.

So the first collections improvement available to most firms is not a better reminder schedule. It is an invoice that cannot be set aside.

Narrative matters more than practitioners expect. "Professional services rendered" is a request to be trusted; a client who is deciding what to pay this month will choose the invoice that justifies itself.

Description should be specific enough that someone who was not in the matter can see what happened, and grouped so the shape of the month is legible. This is also where disputes are prevented rather than resolved: an itemised statement invites a question about one line, while an opaque one invites a question about the whole bill.

Tax errors are the most common reason a legal invoice is bounced by a client's finance team, and they are almost always the same error: applying one rate to a whole document that contains more than one kind of charge.

Professional time is usually taxable. A court fee advanced on the client's behalf is often a true disbursement, outside the scope. A rebilled third-party cost may follow either treatment depending on how it was incurred. Getting this right is not fussiness — an incorrectly taxed disbursement is an error in the client's records as well as yours, and their accountant will find it.

For anything unusual in size or scope, a proforma sent first converts an argument into a conversation. The estimate is not a receivable, so nothing is at stake in the accounts; the client has room to query without refusing an invoice.

The discipline that makes this work is that the proforma must be structurally separate — its own sequence, excluded from revenue, unpayable. A "draft invoice" that can become real with a status change teaches everyone to treat estimates as bills, which is exactly the ambiguity you were trying to remove.

"I never received it" ends most chasing conversations, because there is usually no way to contradict it and no advantage in trying.

Sending an invoice as a link the client opens, rather than an attachment that vanishes into a mailbox, changes the position: the firm knows when it was first opened, and can record an acknowledgment if the client gives one. That is not about catching clients out. It is about removing an excuse that costs firms weeks, and about knowing when the real answer is that the invoice genuinely never arrived — which happens more than firms think, for reasons covered in the piece on deliverability.

Payments arrive in parts, out of order, and by several routes. Two failures recur: the same payment recorded twice because a page was refreshed or two people were being helpful, and a receipt nobody can later tie to an invoice.

Recording settlement against the invoice, with a guard that makes a retry resolve to the same result rather than a second one, removes the first. Issuing receipts on their own sealed sequence removes the second.

Mersal rules tax per line, so taxable time and exempt disbursements sit on one honest document. Proformas issue on their own serial, never count toward revenue or outstanding, and cannot be paid; converting one recomputes tax from the stored per-line rates under a compare-and-swap, so a double conversion is impossible.

Invoices are emailed with their PDF and opened on a hosted page, so the firm sees when the client first opened it and records their acknowledgment if given. Reminders schedule from the due date and fire without anyone remembering. Settlement records partial or full payment behind an idempotency key, so a network retry cannot double-record; receipts issue on their own sealed serial and go to the client. Every step is written to an append-only ledger.