The estimate said one thing, the contract said another, and the invoice — typed fresh in some other program — says a third. Nobody notices until the customer does, and by then you are arguing about your own paperwork in front of the man who owes you money.

A customer who sees the exact draw he agreed to pays it — one that looks re-worked gets questioned. The schedule becomes one draft per draw, not one invoice with three lines, because the down payment goes out in May and the final in October, on two different days with two different due dates.

To know whether a job is behind on money you open its invoices, then its change orders, then add it up in your head.

An owner glancing at a job should see the money trouble before he goes looking for it. The bills and the extras that feed them are one story, so they live in one card — and the closed card does the adding.

Billing the whole job when you meant to bill a draw, or retyping four lines you already wrote in the estimate and getting one of the four wrong.

The office shouldn't have to remember which lines get taxed — the line should know. Putting the kind on every row lets the arithmetic differ per line, so a change order that already carried its own markup and tax is never taxed twice.

Somebody rebuilds the estimate in August to price a second building for the same customer, and the September draw goes out $3,460 above the contract the customer signed in May.

A customer who gets billed more than he signed for stops trusting every bill after it. Pointing an invoice at a different estimate stays possible, but it is confirmed, explained and recorded — changing what a customer agreed to should cost you a sentence of typing.

The invoice goes out in March for a change the customer agreed to in November, and now it is a conversation instead of a payment.

An extra the customer agreed to should arrive as part of the plan, not as a surprise. A bill they have already read never changes underneath them, so merging only goes into drafts — and otherwise the extra becomes the next numbered payment.

The bank funding the build sends the draw back because the loan number is not on it, the office finds out nine days later, and the pour slips a week.

The bank funding the build is the one customer who will send a bill back over one missing field. Lender and loan number are their own fields, pulled from the signed intake form at creation and on demand — never changed silently after the bill has gone.

The building specs print on every bill, so a two-line final payment arrives as a three-page document and the customer reads it as a new quote.

A two-line final bill shouldn't arrive looking like a new three-page quote. The switches live on each invoice with an account-wide default behind them, and the heavy blocks — specs and site address — start off, because the plain layout is what most bills want.

A two-man outfit's invoice looking like a two-man outfit's invoice, on the one bill that goes to the customer's bank.

A small outfit looks like a real company when every bill matches. Branding is set once, at the company, so three invoices on one job can never look like three different firms.

The PDF the customer downloads has a scrollbar, a Send button and half a status pill baked into the top of page one.

What you approve should be exactly what the customer saves — no surprises in the PDF. The PDF is the browser's own print of the one layout, so the copy you checked and the copy they file cannot drift apart.

The customer asks for the invoice again, you go and find it, you email it, it lands in spam, and a fortnight later they ask again.

A customer who can find his own bills stops emailing the office for copies. The card leads with what is unpaid and folds what is settled underneath, because he opens it to answer one question: what do I owe?

The invoice goes out as an attachment, the customer opens it on a phone that will not preview it, and a $25,728 draw sits unpaid for nine days over a file format.

A customer who has to make an account to see a bill pays it later. The link carries the access instead of a password — which is why the link itself is built so nobody can guess another.

One customer's invoice is number 0041, so the next is 0042, and anyone who tries it is reading a neighbour's contract price.

Your customers trust you with their numbers — one guessable link would break that. The access lives in the link, so the link is 24 bytes of real randomness, not a number anyone can count up from.

You ring about the overdue draw and open with "did you get it?", they say no, and you spend the call re-sending a bill they read three weeks ago.

Knowing a bill was read changes the phone call — you chase a decision, not a lost email. The stamp is written by the page that serves the bill, not an email pixel half the mail apps block, and it records the first open, not the last.

The invoicing tool assumes every payment is a card payment, so a builder taking a wire marks things paid with a note in a memo field. Within a month the software's idea of who has paid and the truth have nothing to do with each other.

Builders get paid by cheque and wire for good reason — the software should match the way the money actually arrives. 2.9% of a $93,000 building is $2,707, so this is the main way money is recorded, not a fallback for people without a card reader.

Sending the same $25,728 draw twice, which reads to a customer as either incompetence or an attempt.

Sending the same draw twice makes you look careless at best, and like a grab at worst. A warning gets dismissed at six in the evening; a rule in the database holds for every path — the editor, the schedule, a second tab.

Double-keying a deposit at month end, so the job reads paid, nobody chases the real balance, and the shortfall turns up when payroll runs.

A cheque keyed twice makes a job read paid when it isn't — and nobody chases the real balance. The rule is narrow — same reference and same amount — because a refusal people don't learn to click past has to be one that's always right.

A mistake tidied away in October, and a set of books in January that no longer matches what happened.

Your accountant needs the books to say what actually happened — even the mistakes. Void, delete and reverse are three jobs with three consequences, so they are three separate actions, and none of them can quietly rewrite a financial record.

Fixing a bounced cheque by editing the payment, leaving a job that reads paid and no trace that anything was ever wrong.

A bounced cheque should leave a trail you can explain a year later, not a job that silently reads paid. Totals are rebuilt from the payments that still count, on the server, so a stale tab can never write a number that contradicts them.

You catch a draw billed twice while scanning the month's totals, then lose track of which one it was somewhere on the way into the job to fix it.

You catch mistakes while reading the month's totals — so the fix sits right there. It is no more casual for being close: the invoice keeps its number, stays visible struck through, and needs a written reason.

Answering "what has this job actually paid" means opening four invoices from a list and closing four back to it, and by the third one you have lost track of which you have read.

Reviewing what a job owes should be a swipe through its draws, not four trips back to a list. Each draw has its own colour, so you always know which one you are reading.

A flat list of every invoice you have ever raised, where answering "what does this customer still owe me" means adding up rows on the back of an envelope.

The question you actually ask is "what does this job still owe me?" — so that is the first thing on screen. Jobs sort by recent activity, so this month's billing floats to the top without a filter.

Going through a run of invoices you lose your place and open the same one twice, which happens constantly and costs you the whole review.

Going through a pile of bills, losing your place is what wastes the afternoon. The trail marks where you went in and came out, then clears itself after three seconds, so it never becomes clutter.

Knowing what the business is actually owed means opening job after job, adding balances by hand, and still not trusting the number by the time payroll runs.

An owner wants one honest answer to "what am I owed?" — and a separate one to "who do I ring today?" Overdue is broken out from outstanding and worked out live from the due dates, so there is nothing to close at month end.

Money in lives in one program and money out in another, so nobody can say how the month actually went until the accountant does.

An owner thinks about money as one picture — what came in and what went out. Putting invoices beside crew and sales payouts answers "how did we do?" on one screen, without anyone adding two reports together.

A customer rings about a bill from three months back and you are guessing which job it belonged to, opening projects one at a time until it surfaces.

When a customer rings about a bill from March, you want it on screen while he's still talking. Status chips filter without losing your search, and the list groups by job because one customer can have several.

Work finished in June gets billed in August, because on the day you meant to raise it you could not find anywhere that invoices start from.

Work that's finished should be billed the day you think of it, not when you find the right screen. Asking which job first means the invoice is born attached to its customer, estimate and contract — in the same editor you already know.

Marking a $17,000 wire paid in the books, forgetting the job screen, and chasing a customer who paid you eleven days ago.

Your bookkeeper shouldn't have to tell you a customer paid. When the books are connected they are the authority on money, so a payment entered there marks the bill paid here — one place to enter it.

The bookkeeper trusts QuickBooks, the builder trusts the job screen, and the argument about who has actually paid happens at month end with two different answers on the table.

A customer's bill should never wait on your accounting software. The push is decoupled from the send: if QuickBooks is down the bill still goes, and the invoice says plainly that the books didn't get their copy.

The bank wires a $60,480 draw, nobody records it on the job, and the job reads as owing money it has already been paid.

The money from the bank is still your customer's money paying for his building — it belongs with the job's bills. Recording it once per draw means the job's totals tell the truth without a second set of books for the loan.