Billing
The uninvoiced pool, invoices from draft to paid, and payments in and out.
Connecting payments
Billing runs on the firm's own payment account, connected once from Settings → Integrations; see firm settings for the connection steps. Until the connection is finished, billing surfaces stay out of the way.
The agreed price
The number the client agrees to in the engagement letter is the matter's price, and billing works from it. There is one place that number lives, so the letter and the invoice can't quietly disagree.
It starts as the package's price, so a matter has a figure from the day it's attached. A package can carry two prices, one for an individual and one for a couple, and the attached price is the one that matches the matter, so the starting figure is right without anyone reaching for a second package. See packages for how those prices are set.
Staff set the real one as currency fields rather than typed-in text: the total, any upfront payment, an hourly rate where the engagement is hourly. There are two places to do it. Edit matter holds them alongside the matter's other standing facts, and the dialog that drafts the engagement letter asks for exactly the fee terms that letter prints, at the moment you're deciding them. Either way it's the same number, and saving it in the draft dialog updates the matter. That's the number the letter prints and the number invoices work from. Signing the letter locks it in, and if a redline changed the terms, the signed letter wins going forward. Redrafting a letter against a figure the signed one didn't have says so before it generates.
Agreed price
$4,800
from the package, set on the matter
Adjusting the price adjusts only what hasn't been invoiced yet. Money the client has already been billed or has already paid is never rewritten behind their back; if a new price would fall below what's already invoiced, that's raised for staff to handle deliberately rather than auto-credited. Where an hourly rate is agreed on the matter, it's the rate that applies to time entered on that matter, and time already logged keeps the rate it was entered at.
What's waiting to be billed
The Billing tab opens on the uninvoiced pool: everything this matter has accrued and nobody has billed yet. Attaching a package puts its price there, logging time puts the time there, and anything else staff capture lands there too. The pool is the one ledger of what's owed but not yet asked for.
An invoice is composed out of it. Tick the items this invoice covers and Draft invoice turns them into one, which opens on its own page ready to edit. Where the matter has an insurer as well as a client, you choose which of them this invoice is for at the same moment. An item can also be billed for less than its full amount, in which case the remainder stays in the pool for whoever owes it.
Uninvoiced pool 4 items · $5,417.00
Revocable trust package
Review of prior deed and title report
County recording fee
Transfer-on-death deed · added to scope
Add charge is the single door for anything the client owes for that didn't arrive on its own. It asks what the thing is, and the answer decides how much else happens:
- A charge is money only: a filing fee, a courier, a recording cost. It goes straight to the pool with a description and an amount.
- A service or a document is work, so it joins the matter's scope as well and carries the price you give it. The price is optional here, because plenty of scope work is already paid for by the package it belongs to.
Removing something from a matter's scope reverses what it accrued, as long as it hasn't been invoiced. Anything already invoiced stays, and the remove dialog says so before you confirm.
Logged time, and correcting it
Logging time puts two things on the matter: the entry in the log, which is the record of work performed, and a charge in the pool, which is what the firm has decided to bill for it. They start out saying the same thing and they don't have to stay that way.
The entry itself can be corrected while its charge is still uninvoiced: the date, the hours, the rate, and the description are all editable from the row, and the amount follows the hours and the rate rather than being typed. The correction carries through to the charge in the pool, with one deliberate exception. If someone has already adjusted that charge by hand, the adjustment is kept, and saving the correction tells you so, because rounding $412.50 down to $400 was a decision about billing and re-deriving the amount would quietly undo it.
Removing has two meanings and two places, on purpose. Removing the charge leaves the entry standing: the work happened, the firm isn't billing for it. Removing the entry means it shouldn't have been logged at all, and takes its uninvoiced charge with it. Once the charge is on an invoice, both freeze together and the correction goes through the invoice instead.
The billed amount never writes back to the log. A written-down charge is a billing decision, and the hours stay what they were.
Asking for a deposit
A deposit isn't a separate charge, it's the first slice of what the client already owes. Mint deposit, above the pool, opens with the amount the engagement letter agreed and lets you change it. The dialog then shows which pool items that amount consumes, taking them oldest first, and you can toggle individual rows in or out; the slice re-computes as you do. Where the amount lands part-way through a row, that row is split: the invoice bills the part you asked for and the remainder stays in the pool for later, marked Partial on the invoice so nobody reads it as the whole thing.
Confirming drafts an invoice like any other. Issuing and sending it are still separate, deliberate acts.
Two kinds of matter never see the button. One whose engagement letter agreed no deposit says so in place of it, and one covered by legal insurance doesn't mint deposits at all, because the billed number comes from the claim.
An invoice from draft to paid
An invoice moves through three states the firm controls, and one the client does. A payment made through the checkout lands back on the invoice on its own; there is nothing to mark off by hand and no reconciliation to keep alongside.
A draft is a working document. Its lines are editable, it carries no invoice number, and nobody outside the firm can see it. Abandoning a draft costs nothing, which is the point of it having no number yet.
Issuing is the moment the firm commits. The invoice takes the next number in the firm's sequence, its lines freeze, the PDF becomes available, and a payment can be recorded against it. Issuing is where a firm stands behind a figure, so it's open to attorneys and admins; everything else on the invoice stays open to any staff member.
Issuing asks for the issue date, and that date is the one the invoice carries. It opens on today, which is nearly always right, and it takes an earlier date for work being entered after the fact, so a claim written up in August for work done in June reads as June rather than claiming to have been issued after it was paid. Choosing an earlier date never changes which number the invoice gets: numbers are handed out in the order invoices are issued, full stop.
Sending is a separate choice, not the next step. It emails the client the invoice and a payment link. A client who pays by check at the signing table never needs it: you issue, record the check, and the invoice is settled without anyone being emailed a link for money already in hand. On an insurance matter, submitting the claim takes the place of sending, and it asks for the date it went out for the same reason issuing asks for its own: a claim recorded a week later should still say when it was actually submitted.
HV-0142
IssuedActivity
- Drafted from the pool · Apr 16 · Ines Vane
- Issued as HV-0142 · Apr 16 · lines frozen
- Not yet sent · sending is a separate choice
Still in the pool
Revocable trust package · remainder $3,300.00
Each invoice opens on its own page from the Billing tab. The tab lists them as rows carrying the number, where each one stands and the date it got there, and the amount; the row opens the invoice. An invoice has one surface, so a row and the page it opens can't tell you two different things. The page leads with the balance, carries that ladder across the top with a note naming the next act, and keeps every date on one line under the heading. Back to billing returns you to the tab.
An invoice looks the same wherever it's seen. The PDF the firm downloads, the copy attached to the client's email, and the copy the client downloads from their portal are one document in the firm's own branding, with the firm's name and logo, the attorney of record where the matter has one, lines set out as description, quantity and rate, and amount so a payer can check the arithmetic, and a "How to pay" block naming where to pay and who to make a check out to. The invoice page is the work surface rather than a second rendering of that document, so there is no preview of the preview to keep in step.
The document also says which state the invoice is in instead of reading the same in all of them. A written-off invoice is marked as written off and drops its payment instructions, because nobody is being asked to pay it. Payments received print as dated rows above the amount due; money that went back prints below it, since a refund doesn't reopen what's owed.
Editing a draft invoice
While an invoice is still a draft, its lines are editable: add a line, change a description or an amount, split one line into two, remove a line, or reorder them. This is what makes a negotiated rate possible. Where an insurance plan pays a set amount for work the firm prices differently, staff adjust the draft to the rate that will actually be claimed rather than sending an invoice nobody will honor.
Itemize package contents is the other half of the same idea: one click appends the package's documents and services as indented lines beneath the priced package line, each showing "included" rather than a price. A payer sees what was delivered without the firm inventing a price per document. The sub-lines are ordinary lines once they're there, so removing them while the invoice is still a draft takes the itemization back off.
Some payers want it the other way round. Where a plan pays per document rather than per package, price the sub-lines through the ordinary line editor and each one prints its own money instead of "included", still indented under the package it belongs to. Move the whole amount down that way and the package line above stops printing figures altogether, since "$0.00" sitting above priced lines reads as a contradiction rather than a total.
The header above the lines stays editable a little longer than the lines do. The due date is schedule rather than substance, so it stays editable while the invoice is still being collected, and it can be cleared back to nothing for an invoice that isn't on a clock. On a matter with more than one client, which of them the invoice is addressed to is editable while it's a draft and frozen once it's issued; it can only ever be one of the matter's own clients. Each saves as you change it.
The reason the freeze lands at issue is the same reason the number does: what a client or an insurer received is exactly what they can go back to, permanently.
Voiding and writing off
Two different facts, and they used to get confused because only one of them was available.
Void is "we shouldn't have billed this". It's offered on a draft, on an issued invoice, on a sent one, and on a claim already submitted to an insurer, as long as no money has come in against it, and it asks before it acts. Whatever the invoice claimed from the uninvoiced pool returns there, ready to be billed another way. A void draft never had a number, so nothing is spent. Anything further along keeps its number and stays in the record as void, which is what explains the gap in the firm's sequence to anyone reading the books later. Voiding a sent invoice also stops its payment link resolving, and the client is not emailed about it.
Write off is "we won't collect this", which presupposes having asked. It stays where it was, on an invoice that has already gone out.
Closing the invoice page leaves a draft where it is, to come back to. If there are line edits you haven't saved, you're told before they're dropped.
Correcting an invoice that went out wrong
A committed invoice can't be edited, so the correction is to void it and bill again. That's one act rather than two. Void and reissue, offered in the same confirm as the plain void, closes the invoice and opens a replacement draft over exactly the items the void just returned to the pool. An invoice that is already void offers Reissue on its own, which picks up whatever of its items are still waiting to be billed and tells you if something has been billed elsewhere in the meantime.
The two invoices are linked, and each says so where it's read. The void carries "Replaced by #46" and the replacement carries "Replaces #44", each a link to the other, and the replacement's document names the invoice it replaces in a single line, so a client reading a correction doesn't read it as a second demand. The replacement is an ordinary draft: editable, and it takes its own number when you issue it.
One thing to know before you click. The replacement is rebuilt from the pool rather than copied, so hand-typed lines, edited descriptions and amounts, and itemized sub-lines don't carry over; you redo those on the new draft. The confirm says so.
A written-off invoice isn't reissued. Writing off says the bill was right and the firm won't collect it, so there is nothing to correct.
Correcting a date that was recorded wrong
A wrong date isn't a wrong invoice, and it shouldn't cost you a void. Correct dates, in the menu on an issued invoice, repairs the day it was issued and, on a claim, the day it was submitted. Repairing the issue date is open to the people who could have issued it in the first place; repairing a claim's submitted date is open to any staff member, the same as marking it submitted was. The number, the status, the amounts, the payments, and the record of when the client was emailed all stay exactly as they are, and the correction is kept with what it changed and an optional note saying why.
Two things the dialog tells you before you save. Changing the issue date changes the date on the PDF from then on, and a PDF already sent outside the platform is not replaced by it. And a submission dated after a payment was recorded is allowed but flagged, because history entered late is often messy and the platform would rather say so than refuse the truth.
Payments that arrive outside the portal
Not every payment comes through the checkout. A check, a wire, or an insurance provider's payment is recorded on the invoice by hand, with the amount, the method, a reference if there is one, and the date it was received. That date is the one the invoice reports as paid, so a check that arrives on the last day of a month is recorded there rather than on the day someone got around to entering it.
A recorded payment can't exceed what's actually outstanding. Enter more than the balance due and the invoice refuses it, naming the balance. There's nowhere for the excess to live, so accepting it would only overstate what the firm has collected; a genuinely larger check is recorded at the balance and the difference is settled outside the platform.
Every settled payment has a receipt, whether it came through the checkout or was recorded by hand. It's the invoice document with a receipt heading, showing the payment it's for, the payments before it, and the balance after, and it's the same PDF wherever it's opened: from the payment's row on the invoice, from the payments register, or by the client from their portal. The platform doesn't email it; it's there to open and to print.
When a payment takes a few days
Card payments settle in seconds. Bank transfers take a few business days, and during that window the platform says so rather than pretending nothing is happening. The invoice shows the attempt as in flight, the client's portal row reads "Payment processing" with no Pay button on it, and reminders leave it alone. Nobody gets chased for money that's already moving, and nobody pays twice.
If the transfer bounces, the invoice returns to what it was and the firm's notification bell says so. The client sees the reason in their portal alongside a working Pay button, so they can fix it without calling.
When money comes back
Refunds are issued from the invoice. A card refund is immediate. A bank refund settles over days like the payment did, and shows as processing until it lands; if it fails, the invoice goes back to reflecting money the firm still holds rather than money it returned.
Chargebacks are the other direction. When a client's bank claws a payment back and the firm loses the dispute, the invoice stops reading as paid: the balance reopens for what's no longer covered, and the bell tells staff. No email goes to the client, because the dispute is their own act and how the firm responds to it is the firm's decision.
The payments register
Billing → Payments is the firm's record of money actually received: every payment by every method, card, bank, check, wire, insurance, or other, newest first, with refunds and lost disputes in the same list as negative rows so the list adds up line by line. A period picker across the top offers this month, last month, this year, or a range of your own, and the figures follow it. The strip above the rows reads net collected for the period, which is payments less refunds and reversals, gross beside it, refunds and reversals on their own, and the year to date, with a line beneath splitting the period by method. Net is never rounded up to zero: a month in which more went back than came in reads as a negative figure, because that's the month worth noticing.
Each incoming payment's row links to its receipt, and a card or bank payment also links to the payment processor's own record of it, which is where disputes and card detail live. The processor's own payments view stays available beneath the register for anyone who still wants it. The register is open to attorneys and admins.
Receivables
The receivables board (Billing → Receivables) shows every open invoice grouped by where it stands, across all matters, alongside the work that's been done but not yet billed.
An issued invoice that was never sent sits on the unbilled side with a cue saying so. That's deliberate: the firm has committed a number but hasn't asked anyone for money yet, and counting it as billed would hide a real worklist behind a healthy figure.
Some matters are never going to be billed, and the board shouldn't keep asking. Waive billing on the matter, from the matter's own action menu, says so with a reason: the matter stops appearing as work waiting to be invoiced, and its Billing tab carries a "Billing waived" note with the reason and a way to reinstate. A waiver is about work not yet billed, so an invoice the client already owes stays owed and stays on the board. Nothing is deleted either way.
Insurance-paid matters
For matters covered by a legal insurance plan, the payer can be the insurer rather than the client: provider plans are registered once, a covered matter records its coverage, and invoices to the insurer are tracked alongside client-paid ones.
A covered matter accrues nothing from its package. What the plan allows is settled per claim, so asserting the firm's retail price as a receivable would only be a number nobody is going to pay. Attaching a package to a covered matter says so before you click, and afterwards the package's price appears on the matter's scope as a reference figure with the reason beside it. It counts toward no total anywhere.
Where coverage is added after the package was already attached, nothing is rewritten behind you. Each package charge still sitting in the pool says so on its own row: coverage is active, the claim carries the billed amount, so this can be removed. Staff clear them or keep them, a row at a time, and the row already carries the Remove that does it. Anything already invoiced is never touched.
The claim PDF is the artifact a submission asks for, and it's available from the moment the invoice is issued. That's what issuing is for on this side too: it makes the document permanently reproducible, so what you submitted and what you can re-download are the same thing. Itemized lines print indented under the package line, showing "included" where the package carries the price and their own amounts where the plan pays per document.
On a matter where the plan covers part of the work and the client owes the rest, both sides come off the same pool. You bill the covered part to the insurer, and the remainder stays in the pool to invoice to the client, with the invoice saying which of the two it is. The claim's own page lists what it doesn't cover, each row carrying a Bill action naming the client, so the remainder gets billed from where you noticed it.
Where a matter has both payers, the Billing tab's figures carry a split sub-line rather than a second set of boxes, so "billed" and "due" each say how much is the claim's and how much is the client's.
Reminders
The firm can have the platform chase an unpaid invoice on a schedule it sets, rather than remembering to. Reminders are off until the firm turns them on, they stop the moment the invoice is settled, they leave a payment that's still clearing alone, and both they and the invoice email itself can be written in the firm's own words. See client communications.
The invoice page says where its own reminders stand, in one line beneath the payments: when the next one is scheduled, or that one is going out today, and how many of the firm's cap have already gone. When none is coming, that line names the reason rather than going quiet. It reads paused while a bank payment clears, stopped where the balance is disputed or where nothing is owed, complete at the cap, off where the firm hasn't turned reminders on, or blocked. Blocked is the one that wants a person: either there's no client email on file or the one on file is bouncing, and the line says which, because the fix is different.
Billing never gates the work
Payment status is its own axis. An unpaid invoice doesn't freeze drafting, and closing a matter doesn't bury what's still owed; it stays visible on the receivables board.