Skip to main content

PBJ Invoicing — Changelog

Current release: 7.35 (September 2026)

7.35 — 23 September 2026

No database change; DB stays 11 and the PBJ CRM floor stays 7.44. The phone notification needs PBJ CRM 7.55 or later.

  • Paid & accepted on the bell. When an invoice is paid or an estimate is accepted, the document’s agent (or whoever created it) sees it on the bell under a new Paid & accepted row. Open the document, or press Dismiss, to clear it. You are never told about your own action, and only about documents you can still open.
  • And on your phone, if they have switched notifications on in the CRM (My settings).

7.34 — 22 September 2026

No database change; DB stays 11.

  • Totals are worked out in one pass instead of three, which speeds up long invoices and the nightly late-fee run. Same money, same rounding.

7.33 — 21 September 2026

If you updated to 7.32 earlier today, please update again — this release fixes a problem in it that can affect your totals. No database change; DB stays 11. Needs PBJ CRM 7.53, so update both together.

  • A late fee no longer disappears when you simply save. In 7.32, opening an invoice in Edit and pressing Save changes — even without altering anything — could quietly turn an automatic late fee into an ordinary line: the Late fees figure dropped to zero, the invoice recorded a waiver you did not ask for, and on an invoice carrying tax or a discount the total could move. Saving is safe again.
  • Late fees are the system’s to write. Saving an invoice can no longer add a late fee, change one’s quantity or price, or drop one by leaving it out. Whatever is saved, the fees the system worked out are put back exactly as they were.
  • Removing the fee line yourself still waives it, exactly as it did in 7.32 — and that is now the only thing that waives a fee, so it can only happen on purpose.
  • The fee line is delete-only in the editor. Its Qty and Unit price are shown read-only — you can read the figures but not change them, on a keyboard or a phone — while its Remove still works and every other line is edited as normal.

7.32 — 21 September 2026

This release also carries 7.31. Update PBJ CRM at the same time — the new document head below is drawn by the CRM, and the minimum stays 7.44. Database 10 to 11 — one additive step, and it has already run on a live MySQL host. Take a database backup before you update, as always.

  • A late fee is a line on the invoice now, and you can delete it. Open Edit invoice and the fee sits with the work, titled “Late fee”. Remove the line, save, and the fee is gone from the invoice and from the amount owed. That is the whole of waiving a fee — there is nothing else to switch off and no figure to correct by hand.
  • Your totals are exactly what they were. A late fee is never discounted and never taxed: it is added after the discount and after the tax, precisely as before. Upgrading does not move a single total on a single document.
  • Fees you have already charged are carried across. Every open invoice gets its existing fees written out as lines when you update, so the fee you can see is the fee you can remove.
  • Waiving a fee does not stop the next one. The overdue clock is unchanged: if the invoice is still late when the next fee is due, it is charged. Removing a line forgives that charge, not the schedule.
  • Duplicating an invoice, or turning an estimate into one, leaves the fees behind. A new document starts with the work, never with somebody else’s late fees.
  • A saved invoice or estimate now reads like its edit screen (7.31). The kind, number, customer, agent and dates sit in a head that stays put while you scroll, and the buttons are down in the action bar.

7.30 — 19 September 2026

This release also carries 7.18 through 7.29, which ran on our own site before being published together. Update PBJ CRM to 7.44 or newer first (7.50 is current). Database 8 to 10 — two additive steps (the deposit on a document, then a typed Bill to); both have already run on a live MySQL host. Take a database backup before you update, as always.

  • Deposits on estimates and invoices. Require a deposit as a percent of the total, a flat amount, or the line items you tick, with a deposit note written for you from the figures. The customer’s page, the PDF and the email all show what is due now and what is due on completion.
  • Paying a deposit accepts the estimate, which converts it into an invoice with the payment already applied. Deposits are not refundable, and the documents say so in one sentence.
  • Clear buttons for the customer. An estimate with a deposit reads “Accept and pay deposit by card” / “Accept and pay deposit by check”, with the other ways to pay the deposit listed below; the email button reads “View and accept estimate”.
  • One button on the estimate PDF — “Accept and pay deposit”, or “Accept” when no deposit is needed, which accepts straight away. The links in every invoice PDF are now real, clickable links.
  • A new editor. Title in the header, the customer’s card with their address and a Bill to you can edit (stored and printed on the page, PDF and email), dates and recipients on one screen, and live totals as you type. A new line starts at quantity 1 and the arrows step by 1, while typed fractions still work.
  • Fixes: a deposit set on a sent document now saves; Pay by card appears whenever a processor is connected in PBJ CRM; an estimate edited from its record stays an estimate; the recurring editor opens for profiles that have line items; money shows again on the Events screens; the redundant Open button is gone and Edit opens the editor again.

7.17 — 11 September 2026

Update PBJ CRM to 7.35 first — this release needs it, and PBJ CRM 7.35 carries a database change (27 to 28) that has not yet run on a live MySQL host. Take a database backup before you update. There is no database change in this plugin.

This release also carries 7.08 through 7.16, which were tested on our own site rather than published one at a time: totals recalculating as line items change, safer recovery of abandoned payment webhooks, saved-line visibility enforced on write, invoice activity drawn as the CRM’s compact timeline card, Convert+ opening the invoice it created, unpaid invoice cards reachable by keyboard, recording a payment from the invoice itself with tax and balance due, invoices and estimates requiring a title, “Quoted, not yet owed” on the money report, and provenance written in words on a converted invoice.

  • An invoice opens in the CRM’s new three-pane record page, with a detail centre: the TOTAL / PAID / BALANCE DUE strip, the line items, and the totals block. Line items are read-only there — the full line-item editor is still one click away as Edit line items & totals in the More menu. Open thread swaps the middle to the conversation and back.
  • BEHAVIOUR CHANGE: an employee who owns an invoice now SEES Void. The server had always accepted that void — the button was simply hiding it, so the two disagreed. The server permission is unchanged and has NOT been widened; the button now tells the truth about what the server will do.
  • An invoice still has no Delete, and will not get one. An invoice is voided, never binned: a voided invoice stays readable and countable, and it drops out of Money owed to you. Estimates are unchanged — no Void and no Delete; a quote is declined or it expires.
  • The core Edit now edits the invoice’s own facts — issued date, due date, terms. Status is not editable there, because changing an invoice’s status is a flow with its own dialog.
  • Fixed: an estimate was showing “Collected — $0.00 of $276.06”, which is invoice wording on a quote nobody owes. That bar is invoice-only now.

7.07 — 7 September 2026

  • Housekeeping: the translation template shipped with the plugin (languages/) had been left behind at an older version, so it no longer matched the text in the plugin. Ten strings that exist in the plugin were missing from the old template, so a translator working from it could not have translated them. It has been regenerated. No code, settings or database change — the plugin behaves exactly as 7.06 did.

7.06 — 6 September 2026

  • Invoices edited after they were sent now say so on the customer’s own page and in the PDF, in the same words as the email: “This replaces the copy sent on …”. An invoice nobody has edited is unchanged.
  • A designed invoice layout can no longer drop a way to pay: the “How to pay” methods and their payment codes are placed under the totals when the layout does not position them itself.
  • Payment codes in the PDF are taken from the full-size image rather than the small one, so they scan off paper.

7.05 — September 2026

  • Invoice links are never tracked. Declares its public /pbj-inv/ route to the CRM’s click tracking (services contract 33, filter pbj_crm_tracking_skip_paths), so a marketing email carrying a pay link keeps it untouched: never rewritten through the click redirect, the token never stored in the CRM’s links table. Declaration only; the database is untouched.
  • The money, in a marketing email. A second field group, The money, is declared to the CRM’s palette as a per-contact one (services contract 35), so a marketing email, a letter or a document — none of which has an invoice behind it — can now offer five fields about the PERSON being written to: {invoice_number} their latest unpaid invoice, {amount_due} what they still owe across all of them, {due_date} when that latest one is due, {pay_link} the link to view and pay it, {late_fee} the late fees on it so far. They are answered on the CRM’s pbj_crm_contact_token_values filter for the contact and, when the contact is a business, for the business’s invoices too — one query per person, memoised, estimates and drafts and voided documents never counted. Somebody who owes nothing gets an empty answer to all five, never “$0.00”, so {amount_due|nothing right now} falls back to the words you wrote. The numbers, the date, the link and the fee are spelled by the same code that spells them in an invoice email, so a figure cannot read one way in one email and another way in the next. The CRM’s own fields always win a name clash, and nothing here is stored: it is read at send time. Guarded end to end — an older CRM never applies the filter, so nothing is offered and nothing changes. The database is untouched.
  • Hotfix — Edit opens the editor again. Pressing Edit on any saved invoice or estimate threw ReferenceError: itemStatus is not defined out of the editor descriptor, the whole invoices section failed to mount, and the panel said “Invoices did not load — Nothing was changed. Try again.”, which reads as a broken LIST and is not one: the list, the record and every REST read were fine. itemStatus() was a helper that has never existed in this file; the two places that called it (the customer chooser’s subtitle and the editor header’s status chip) now read the module’s ONE status vocabulary, STATUS_WORDS through labelStatus() — the same words the list card, the record header and the Status filter already print. No second set of status words was invented. Both calls were on the unconditional path, so this affected every edit of every document. The whole descriptor file was swept for other calls to helpers it does not define; there were none.
  • Hotfix — A payment method can carry a payment code (a QR photo). “Add photos as optional additional ways to pay — Venmo and Cash App QR codes, for example.” This EXTENDS the manual payment methods you already define; it is not a new payment concept and it is not a gateway. Settings → Payment Methods gives every manual method a Payment code column with the same media-library picker the logo uses: choose the QR image once, and it prints beside that method’s name and instructions in all four places a manual method appears — the public tokenized invoice page, the {manual_methods} block a PBJ Templates layout prints, the emailed copy (a plain <img> with a public URL, inline style, no CRM tokens, the method’s own name as its alt text), and the PDF, where it is drawn at 96 pt — 33.9 mm square, above the 30 mm a phone camera reads reliably off paper. Printing the page from a browser pins it to 40 mm for the same reason. No schema change and no migration: manual methods are an array in the plugin’s settings option, so this is one new image_id key beside name and instructions, and a method saved before today simply has no key — which reads as no image, which prints exactly the bytes it printed yesterday (asserted, byte for byte, against the pre-change code). The ATTACHMENT ID is what is stored, never a URL, and it is resolved to a URL (page, email) or to a local file path (PDF) at render time: delete the image from the media library and it vanishes from every invoice, sent ones included, instead of leaving a broken picture behind — and nothing errors. The code rides the invoice’s existing manual_methods_json snapshot the same way the method’s name and instructions always have, through the method id the snapshot already stores. The first-run wizard’s copy of the editor was given the same column, because a wizard that rebuilt the rows without it would have silently wiped every code somebody had set.
  • Hotfix — A re-sent invoice you have edited says it is a revision. Editing a sent invoice and sending it again put a second email in the customer’s inbox that looked identical to the first while carrying different figures. The subject now leads with “Revised” ahead of whatever your own subject template says (“Revised: Invoice INV-0036 from Acme”), the email opens with “This replaces the copy sent on <the original send date> — the amounts and items below are the current ones.”, a text message says “Revised invoice INV-0036” and carries the same sentence, and the invoice’s activity trail records that sentence beside the Resent row. A plain resend of a document nobody has edited is NOT called a revision — the word would stop meaning anything. Nothing was added to the database for this: sent_gmt already holds the date the first copy went out (a resend has always kept it), and the event feed already records edited, sent and resent, so “has it changed since the customer last saw it?” is one query against what is already stored. The public tokenized page and the attached PDF already drew the document’s current rows on every request and are unchanged.

7.04 — September 2026

LAYOUTS – the paper an invoice or an estimate is printed on, designed in PBJ Templates and obeyed by all three renderers (services contract 30). “Rules, not HTML”: the published default layout hands back RULES – paper size (Letter or A4) and margins, whether the top repeats on page 2 and whether the pages are numbered, which line-item columns show and in what order and under what headings, the colours, the font, the logo, the words after the totals – plus its own markup with this plugin’s tokens still in it. The public page prints that markup with the tokens expanded and the FRAGMENTS filled: {items_table}, {totals_table}, {pay_button}, {stamp}, {payments_table}, {notes}, {terms}, {line_notes} and {manual_methods} are blocks this plugin builds itself, per the rules. The carrier email’s {items_table} obeys the same columns and colours, and the wrapper takes the layout’s accent, logo and font. The PDF keeps its own writer and obeys the rules: the page box, the margin, a compact repeat of the top on page 2, page numbers on or off, the columns in order at fixed widths with the per-line DETAIL under the description (drawn for the first time), the ink/muted/line colours, the letterhead logo resolved to a local upload, the closing paragraphs and the pay-button wording. Nine plain tokens are added to the invoice_email palette ({document_title}, {customer_address}, {issue_date}, {status_word}, {business_email}, {business_phone}, {business_address}, {late_fee}, {terms_text}) and filled on every send. Invoicing also declares who uses its layouts – every invoice, every estimate, active recurring billing – and offers your 24 most recent documents as samples with your longest one preselected, so “Check it on paper” draws a real invoice. Money is never recomputed: every figure is the stored one, and the only computed cell on the page, tax per LINE, is display-only and written nowhere. All guarded: no PBJ Templates, an older CRM, or no published default layout and every document prints byte for byte what 7.03 printed. Three fixes ride with it. (1) Attaching the PDF to an email could fatal anywhere outside the website admin – wp_tempnam() lives in wp-admin/includes/file.php, which a REST or cron send never loads – so a scheduled reminder or a send from the portal died where the same send from wp-admin worked; latent since the attachment option shipped. (2) The attached PDF now obeys the layout exactly as the page and the download do, rather than being the one copy drawn the old way. (3) {terms_text} reads the DOCUMENT’s own terms first (its first line), and only then the default-terms setting, so an invoice that says something different about its terms prints what it says. Proven both ways: with the layout unpublished, the page and the PDF of a 14-line invoice, an estimate and a recurring bill are identical to the same three documents with PBJ Templates switched off, and byte for byte what 7.03 draws but for the stylesheet’s cache-busting version number. DB stays 7.

7.03 — September 2026

Invoices finally tells the CRM its fields: the invoice_email token context (customer name, their business, number, total, balance, due date, pay link, business name, the lines as a table) is declared to the CRM’s palette, so an invoice notice or layout in PBJ Templates offers real fields. The five message types (invoice, estimate, reminder, receipt, late fee) are declared to the notice registry seeded with the shipped words, and template() asks PBJ_CRM_Services::notice_for() first — a published designed notice is sent as the finished document it is (tokens swept, {items_table} placed, your note and signature before </body>), otherwise today’s text path runs unchanged. The public invoice / estimate page shows PBJ Templates’ portal notices at the top. All guarded. DB stays 7.

7.02 — September 2026

An invoice, receipt, reminder or late-fee email now carries the sender’s DESIGNED signature from PBJ Templates when they have one, under the message and above the document footer — the CRM’s one seam (services contract 27, filter pbj_crm_signature, context invoice_email), asked with a method_exists() guard so a site without that module, or on an older CRM, sends exactly what it sends today. The signer is whoever pressed Send, else the invoice’s agent, else whoever created it. Nothing else changes; DB stays 7.

7.01 — 4 September 2026

An invoice is Draft, Unpaid, Partly paid, Paid or Voided – and nothing else. The stored sent, viewed and overdue rows all read Unpaid and are mapped at query time, so no invoice data moves; whether an invoice is LATE stays its own separate badge. Estimates and Recurring keep their own vocabularies and no longer borrow the invoice one.

7.0.0 — 4 September 2026

7.0.0 — THE SUITE MAJOR, requiring PBJ CRM 7.0.0. One equal version across the suite. SCHEMA CHANGE: DB 6 to 7 drops the no-op per-invoice reminders_enabled and late_fees_enabled columns. They stopped deciding anything in 1.44.0, when per-document payment chasing was removed — automatic reminders and late fees are SITE settings and were already the only thing any reader consulted — so nothing changes on screen and no invoice data moves. The migration drops one column per statement (a combined ALTER would let a refusal on the second undo the first), verifies BOTH columns are gone before it stamps the version, and heals a half-finished drop on a later request. A PUT that still names either key is refused with the same message it has been given since 1.44.0.

Full release notes: PBJ CRM Suite 7.0.0.

1.44.0 — 2 September 2026

Empty invoice, estimate, recurring and money-owed lists now show a short line drawn with the CRM’s shared empty-state frame, so they match every other empty screen in the portal. No database change.

1.43.1 — 31 August 2026

Invoice lists now load every returned invoice’s line items in one ordered query, and global search resolves company/contact names in two published CRM batch reads. Payloads, item order, company-name precedence, permissions, and database schema are unchanged.

1.43.0 — 30 August 2026

  • A verified payment can no longer be lost to a momentary failure. If recording a payment or refund fails mid-processing, the gateway is now told to retry — instead of being told all is well — and the retried delivery picks the work back up and completes it, exactly once, never twice.
  • A refund that arrives before its payment is no longer dropped. It is acknowledged, held, and reconciled automatically the moment the matching payment is recorded; the daily tick also retries, and an unmatched refund becomes a terminal audit entry after 7 days. Adds one column to the webhook log (database version 6 — the update runs itself and stamps only after verifying).
  • Signature failures and malformed notifications behave exactly as before, and ordinary payment-then-refund processing is unchanged.

1.42.0 — 29 August 2026

  • Invoicing now appears on the CRM’s new “Who can do what” screen – eight rows covering raising and sending an invoice, saving a line for yourself, putting one into the shared price list, recurring billing, voiding, money owed, how an invoice looks, and reminders and late fees.
  • Two rows carry a warning rather than a tidy answer, deliberately. Voiding an invoice and reading money owed both still follow being able to work on that invoice, while the decision of 28 August puts them higher. The screen says so on the row instead of showing the decision as though it had already happened – a table that told you the wrong thing confidently would be worse than no table.
  • Nothing about who can do what has changed in this release.

1.41.0 — 29 August 2026

  • Reminders & late fees are on the front end. Settings > Invoice reminders & late fees now opens in the CRM: the schedule, the grace period, the fee, the repeat, the cap and the “tell the customer” switch, with the same plain-English summary underneath.
  • The warning that nothing can send until your business name is filled in is shown here too, where reminders are switched on – not left to a log nobody reads.
  • Amounts are still typed in dollars and stored in cents, and every limit is the same one the website admin applies. Editing from a phone cannot produce a fee the website admin would not have allowed.
  • The complete screen stays in the website admin as well, unchanged.
  • Invoices can now have their own “Who sees what” setting. A CRM owner can set invoices to open or scoped separately from everything else, and it applies to the invoice list, estimates, “Money owed” and every total. Nothing changes until they set one, and the person a document belongs to always keeps it.

1.40.0 — 28 August 2026

  • SAVED LINE ITEMS ARE PERSONAL FIRST (Access Ladder 23.4). A line you save is YOURS until a manager puts it into everybody’s price list. Before this, anything anybody saved went straight into the shared list for the whole site.
  • DB 4 -> 5: one new column, saved_items.shared. Its DEFAULT is 1 on purpose — every line that already existed is already in everybody’s list, and a default of 0 would have quietly taken all of them away on update. New rows are written 0 by the writer, so the default serves the migration and the writer serves the policy.
  • A manager sees every personal line, because a manager who cannot see a line has no way to promote it. This is strictly a NARROWING for the employee rung and leaves the manager rung exactly where it was.
  • The scope is applied in SQL, so the row cap still caps what this viewer can see rather than capping the table and hiding most of what came back.
  • On a site where the new column has not landed, the list behaves exactly as it did before 1.40.0 — the safe degrade, checked against the database rather than against a stored version number.
  • Refusals now come from the CRM’s own refusal seam where the hub is new enough to build one, and fall back to this plugin’s own sentence where it is not, so the minimum-CRM floor does not move.

1.39.1 — 28 August 2026

  • Translation template regenerated. No change to how anything works.

1.39.0 — 28 August 2026

  • A line can carry its own description. Each row on an invoice or estimate gets a DESC line beneath the figures, so a charge can explain itself without pushing the explanation down into the notes block. Database version 4.
  • The due date honours a setting of zero. A site configured for 0 days was still getting 30, because a zero was being treated as “nothing set”. Fixed here and on the recurring schedule’s own due-in-days, which had the identical fault.
  • Linked records and Activity now appear on an invoice. The panel existed but was reading keys the server does not send, so it was empty on every document ever opened. An invoice raised from a ticket or a visit now shows that link, and the trail of what happened to it.

1.38.0 — 28 August 2026

  • The estimate and invoice editor is rebuilt to one layout. The document down the middle; totals, delivery, notes and terms beside it, or below it on a phone. On a new document an Estimate/Invoice switch changes what you are writing in place. Tax rate, deposit, reminders, late fees and manual payment methods are settings now, decided once — existing documents keep exactly the values they had.
  • A business can be a recipient. An invoice for a company addressed to that company is the ordinary case, and the only way to say it used to be leaving the recipient list empty. Any other business is still refused.
  • The PDF gives your customer a way to pay. It listed the manual methods and nothing else, so somebody holding the download could not reach card checkout at all.
  • The Send window no longer asks for a subject it was throwing away, and it names the address your customer will actually see the email from.
  • A line item with no description reads “Untitled item” instead of being blank.
  • Overdue documents carry an orange dot, and one past the late-fee point a red one, on every list they appear in.
  • Creating or editing a document works again after 1.35.x — the editor was asking for a list at an address that only ever accepted saves, and one refusal took the whole screen.
  • Merging two contacts now moves invoices and recurring profiles onto the survivor.

1.34.0 — 24 August 2026

  • Invoice, estimate, recurring and Money Owed lists now use CRM-owned cards, readers, footer actions and saved workspaces.
  • No-rail readers use the full remaining width, and the Money Owed explainer can be dismissed per signed-in user.
  • Invoice due dates and authoritative recurring next-run dates contribute to the shared Calendar registry.
  • Scoped invoice and recurring work can appear in the CRM-owned Open Work section without module-owned card markup.

1.33.0 — 24 August 2026

  • Invoices, estimates, recurring profiles and Money Owed now use CRM-owned cards, readers and saved workspaces.
  • Readers without a side rail use the full available width.
  • The Money Owed explanation is now dismissible per user.
  • Active recurring profiles contribute their authoritative next-run dates to the shared Calendar.

1.32.0

Your invoice theme and your email templates are now drawn by the CRM inside the portal, in the same look as the rest of the suite — rather than on a screen of their own that looked like a different product.

Nothing about what they do has changed, and nothing you had set has been moved or reset. Only where you find them, and what they look like when you get there.

1.31.0

See late money at a glance. An invoice past its due date shows an orange circle, and one past the late-fee point (a fee has been added, or the grace period has run out) shows a red circle — on the invoice list, the invoice itself and the Money owed to you screen.

1.30.0

Add Work on a person or business profile can raise an invoice directly, for people with invoice access. No database change.

1.29.0

One shared answer to “has this ticket or visit been invoiced yet?” Other PBJ modules can now show View invoice instead of Create invoice when one already exists. No database change.

1.28.0

Invoice line items are usable on a phone. Every line is a full-width labeled card for description, quantity, price, tax, amount, reuse and remove; desktop remains a table. Issue and due dates stay inside the card and retain date-only behavior.

Direct company links now show the authoritative business name, including a business with no contacts. Permitted agents get Find invoices and Create invoice in the mobile menu, plus Create/View invoice actions from completed tickets and visits.

1.27.0

Documents inherit the communication method of the ticket or visit they came from. Email keeps the established invoice mailer, text sends a concise message with the protected document link, and phone starts click-to-call. If no usable origin exists, the agent chooses. No database or minimum-CRM change.

1.26.0

Invoice reporting now lives on the CRM’s unified Reports screen. Invoicing registers its existing Money owed report only while the module is installed, so reports stay useful without showing unavailable modules.

Requires PBJ CRM 1.46.0 or newer. No database change.

1.25.0

New invoices and repeat bills now use the due terms set in admin. A fourteen-day setting produces fourteen days, and an intentional zero means due today; the editor no longer silently falls back to thirty days.

Current invoices now appear in CRM Everything. They are visible on the customer or business record and on the creating agent’s profile, including through that agent’s manager and owner visibility ladder. No database change.

1.24.0

The “Invoices” and “Estimates” headings no longer repeat the tab directly above them.

1.23.0

An invoice or an estimate is now something you can attach things to — tasks, notes and files. The chase-up list for a bill can sit on the bill itself.

The document’s own number is used wherever an attached item says where it lives, never one worked out from its id. Invoices and estimates are numbered separately, so a worked-out reference would disagree with the document you have already sent.

1.22.0

Fixed: the “Pay by card” button your customers see is readable again. On the invoice page your customer opens, that button was invisible until you moved the mouse over it. It now reads properly the moment the page opens. The Decline button on estimates had exactly the same fault and is fixed too. Nothing was ever broken about paying — the button worked all along, you just could not read it.

On your own invoice screen the Edit button now appears once, at the top, instead of twice.

A print button, and a tidier printed invoice.

1.21.0

An assistant can now put lines on an invoice. Before this it could only create an empty one, which totalled nothing and had no way of getting anything onto it. It can now add a line, change a line and take a line off. The arithmetic has not moved: the same multiplication and the same rounding happen in the same one place they always have.

It can also record a payment you have already been given — cash, cheque, bank transfer, or whatever else you have set up by hand. There is deliberately no way for an assistant to take a card payment, and no way for it to give money back; a payment for a negative amount is refused. Repeat bills and the money-owed list can both be read. One thing worth knowing: an invoice an assistant makes stays a draft, because it has no way to move a document on to the next stage.

Money safety: a quantity written with a comma is now refused. On the screen “1,500” sensibly means fifteen hundred. Sent by an assistant, or pasted out of a spreadsheet, “1,5” usually means one and a half — and it was being read as fifteen, a tenfold overcharge, without a word said. An assistant is now told to send a plain number with a dot, for example “1.5”. Nothing about typing quantities on the invoice screen has changed.

1.20.0

“What has changed since” now gives an honest total. Ask an assistant which invoices or estimates have changed since a date and the number it reports is the number that really did change, and it agrees with the documents listed beside it. It used to hand back the total for everything, so the count stopped short of the truth. An assistant asking what has changed now gets the complete answer.

1.19.0

Invoices, estimates and recurring billing are available to the CRM’s new assistant connector (Apps & Assistants) — always as you, seeing only your own slice. Requires PBJ CRM 1.29.0 or newer. Nothing else changed.

1.18.0

The pay button is readable before you touch it. The label colour is now chosen by real contrast arithmetic against your accent colour — on the page, the PDF and the email alike. And “How to pay” says the right thing: with an online payment button on the page the manual methods heading reads “Additional ways to pay”; with no online option it stays “How to pay”.

1.17.0

Invoices, estimates and recurring billing join the suite’s search — and searching by the customer’s name now really works, on the invoice list and in the header search.

1.16.0

The invoicing round-out. Six things, and a database update.

Raise an invoice from a ticket. Any ticket in PBJ Helpdesk 2.15.0 or newer — open or closed — now carries a “Create an invoice” button. Billing a job you only think about after closing the ticket is the normal way round, and until now nothing on a ticket led to an invoice at all.

A savable description under the line items. Write the paragraph that explains what the work was, then press “Save for reuse” and it joins a list you can pick from next time. It is separate from the Notes block, which stays your closing message at the bottom.

A business can be the only recipient. If a business has its own email address in the CRM you no longer have to name a person at it — a company-only invoice is now a normal document rather than something the editor blocks. If there is neither a ticked person nor an address on the business, the save still refuses, and it now tells you both ways to fix it. Recurring profiles follow the same rule.

Standard terms. There is a general-purpose terms template and a “Use the standard terms” button that drops it in as ordinary editable text. The terms box also shows your site-wide defaults as greyed-out placeholder text, so you can finally see what an invoice will say when you leave the box empty instead of guessing.

Re-open a closed invoice. Managers and above get a Re-open button on a paid invoice. It asks for a reason, will not go ahead without one, and keeps the reason with the invoice. Note what re-opening now does: the invoice stays open. It will not put itself back to Paid on the next nightly run — a person decides when it closes again, so a refund or a query cannot be quietly erased.

Database update. Two new columns, applied automatically. It is checked before it is recorded as done, a site left half-finished by an earlier attempt repairs itself on the next page load, and a host that refuses the change is retried a bounded number of times and then told about on screen — instead of being retried on every page view for ever.

1.15.0

The customer box on invoices and estimates can now add somebody who is not in your list yet. Type the name, and if nothing matches, press “+ Add a new person” (or “+ Add a new business”) and fill in the name, email and phone right there — no trip to the CRM in the middle of writing an invoice. Nothing is ever added until you press Save on that little form.

The new box comes from PBJ CRM 1.22.0. With an older CRM, the customer box looks and works exactly as it did before. No database changes.

1.14.0

If you charge percentage late fees, please read this one. A late fee could be applied more than once to the same invoice — and once it started, it repeated every night. It happened when the record of the charge failed to save while the charge itself went through, so the next run could not tell the fee had already been applied. Charges are now recorded first and checked before any money is added. If you use late fees, it is worth looking over your overdue and recently paid invoices and crediting back anything that was charged twice.

A second fee problem is fixed with it: an invoice paid while the nightly run was working through the list could still be charged, which reopened a settled invoice and emailed the customer about it. Every invoice is now re-checked immediately before it is charged.

Percentage late fees are also now applied at the same precision they are saved and previewed at. A 1.2345% fee on a $10,000 invoice charged $123.50 and now charges $123.45 — the figure the settings screen always showed. Nothing you have saved changes meaning.

Also: every money amount is now produced in one place, so the same total can no longer be spelled two ways on the screen and the PDF; changing a deposit between a flat amount and a percentage without giving a new figure is refused rather than silently misread; and the plugin checks that PBJ CRM is new enough, not merely installed. No database change.

1.13.0

Your invoice email templates and your reminder and late-fee settings now appear on PBJ CRM’s Templates & Notifications tab, next to every other add-on’s. Nothing about how they work has changed — only where you find them. Behind the scenes, the “never cache this page” rule now comes from PBJ CRM instead of a copy kept here, and your invoice page, its PDF and the not-found page all send the full set of no-cache instructions on every route rather than only on the routes that happened to add them. No database change.

1.12.0

Two important fixes found in review. Monthly and yearly recurring invoices no longer drift at month end: a profile billed on the 31st used to slide forward and stay slid, and one billed on the 28th or 30th could quietly become a month-end profile. The day you chose is now remembered and kept — the 31st clamps to the short month and comes back to the 31st, while the 30th stays the 30th. Separately, a flood of fake payment notifications can no longer stop genuine ones from being recorded. Also: a bare number typed as an invoice date is read as the date it says instead of becoming a 1970 date.

1.11.0

Saved line items: save the lines you use often and add them to any invoice, estimate or recurring template with one pick — nothing saves as a side effect, and every added line stays editable.

1.8.0–1.10.1

Hosted checkout and signed webhooks for Square, PayPal and Stripe (payments land even if the tab closes; receipts sent automatically); the daily jobs really run — overdue sweep, reminders, late fees, recurring invoices — with a “Run the daily jobs now” button and a dead-cron warning; full mobile pass.

1.4.0–1.7.0

Settings moved inside PBJ CRM; payment credentials live once on the CRM’s Connected accounts screen; invoice email sends through the CRM’s mailboxes; screens follow the CRM theme.

1.0.0–1.3.0

The foundation: invoices and estimates bound to CRM contacts and businesses, whole-cent money math, the tokenized public invoice page with PDF, invoice themes, “Jane at Acme” documents, and the “Money owed to you” screen with aging buckets and CSV.

August 4, 2026

Current release: 7.35 (September 2026)

7.35 — 23 September 2026

No database change; DB stays 11 and the PBJ CRM floor stays 7.44. The phone notification needs PBJ CRM 7.55 or later.

  • Paid & accepted on the bell. When an invoice is paid or an estimate is accepted, the document’s agent (or whoever created it) sees it on the bell under a new Paid & accepted row. Open the document, or press Dismiss, to clear it. You are never told about your own action, and only about documents you can still open.
  • And on your phone, if they have switched notifications on in the CRM (My settings).

7.34 — 22 September 2026

No database change; DB stays 11.

  • Totals are worked out in one pass instead of three, which speeds up long invoices and the nightly late-fee run. Same money, same rounding.

7.33 — 21 September 2026

If you updated to 7.32 earlier today, please update again — this release fixes a problem in it that can affect your totals. No database change; DB stays 11. Needs PBJ CRM 7.53, so update both together.

  • A late fee no longer disappears when you simply save. In 7.32, opening an invoice in Edit and pressing Save changes — even without altering anything — could quietly turn an automatic late fee into an ordinary line: the Late fees figure dropped to zero, the invoice recorded a waiver you did not ask for, and on an invoice carrying tax or a discount the total could move. Saving is safe again.
  • Late fees are the system’s to write. Saving an invoice can no longer add a late fee, change one’s quantity or price, or drop one by leaving it out. Whatever is saved, the fees the system worked out are put back exactly as they were.
  • Removing the fee line yourself still waives it, exactly as it did in 7.32 — and that is now the only thing that waives a fee, so it can only happen on purpose.
  • The fee line is delete-only in the editor. Its Qty and Unit price are shown read-only — you can read the figures but not change them, on a keyboard or a phone — while its Remove still works and every other line is edited as normal.

7.32 — 21 September 2026

This release also carries 7.31. Update PBJ CRM at the same time — the new document head below is drawn by the CRM, and the minimum stays 7.44. Database 10 to 11 — one additive step, and it has already run on a live MySQL host. Take a database backup before you update, as always.

  • A late fee is a line on the invoice now, and you can delete it. Open Edit invoice and the fee sits with the work, titled “Late fee”. Remove the line, save, and the fee is gone from the invoice and from the amount owed. That is the whole of waiving a fee — there is nothing else to switch off and no figure to correct by hand.
  • Your totals are exactly what they were. A late fee is never discounted and never taxed: it is added after the discount and after the tax, precisely as before. Upgrading does not move a single total on a single document.
  • Fees you have already charged are carried across. Every open invoice gets its existing fees written out as lines when you update, so the fee you can see is the fee you can remove.
  • Waiving a fee does not stop the next one. The overdue clock is unchanged: if the invoice is still late when the next fee is due, it is charged. Removing a line forgives that charge, not the schedule.
  • Duplicating an invoice, or turning an estimate into one, leaves the fees behind. A new document starts with the work, never with somebody else’s late fees.
  • A saved invoice or estimate now reads like its edit screen (7.31). The kind, number, customer, agent and dates sit in a head that stays put while you scroll, and the buttons are down in the action bar.

7.30 — 19 September 2026

This release also carries 7.18 through 7.29, which ran on our own site before being published together. Update PBJ CRM to 7.44 or newer first (7.50 is current). Database 8 to 10 — two additive steps (the deposit on a document, then a typed Bill to); both have already run on a live MySQL host. Take a database backup before you update, as always.

  • Deposits on estimates and invoices. Require a deposit as a percent of the total, a flat amount, or the line items you tick, with a deposit note written for you from the figures. The customer’s page, the PDF and the email all show what is due now and what is due on completion.
  • Paying a deposit accepts the estimate, which converts it into an invoice with the payment already applied. Deposits are not refundable, and the documents say so in one sentence.
  • Clear buttons for the customer. An estimate with a deposit reads “Accept and pay deposit by card” / “Accept and pay deposit by check”, with the other ways to pay the deposit listed below; the email button reads “View and accept estimate”.
  • One button on the estimate PDF — “Accept and pay deposit”, or “Accept” when no deposit is needed, which accepts straight away. The links in every invoice PDF are now real, clickable links.
  • A new editor. Title in the header, the customer’s card with their address and a Bill to you can edit (stored and printed on the page, PDF and email), dates and recipients on one screen, and live totals as you type. A new line starts at quantity 1 and the arrows step by 1, while typed fractions still work.
  • Fixes: a deposit set on a sent document now saves; Pay by card appears whenever a processor is connected in PBJ CRM; an estimate edited from its record stays an estimate; the recurring editor opens for profiles that have line items; money shows again on the Events screens; the redundant Open button is gone and Edit opens the editor again.

7.17 — 11 September 2026

Update PBJ CRM to 7.35 first — this release needs it, and PBJ CRM 7.35 carries a database change (27 to 28) that has not yet run on a live MySQL host. Take a database backup before you update. There is no database change in this plugin.

This release also carries 7.08 through 7.16, which were tested on our own site rather than published one at a time: totals recalculating as line items change, safer recovery of abandoned payment webhooks, saved-line visibility enforced on write, invoice activity drawn as the CRM’s compact timeline card, Convert+ opening the invoice it created, unpaid invoice cards reachable by keyboard, recording a payment from the invoice itself with tax and balance due, invoices and estimates requiring a title, “Quoted, not yet owed” on the money report, and provenance written in words on a converted invoice.

  • An invoice opens in the CRM’s new three-pane record page, with a detail centre: the TOTAL / PAID / BALANCE DUE strip, the line items, and the totals block. Line items are read-only there — the full line-item editor is still one click away as Edit line items & totals in the More menu. Open thread swaps the middle to the conversation and back.
  • BEHAVIOUR CHANGE: an employee who owns an invoice now SEES Void. The server had always accepted that void — the button was simply hiding it, so the two disagreed. The server permission is unchanged and has NOT been widened; the button now tells the truth about what the server will do.
  • An invoice still has no Delete, and will not get one. An invoice is voided, never binned: a voided invoice stays readable and countable, and it drops out of Money owed to you. Estimates are unchanged — no Void and no Delete; a quote is declined or it expires.
  • The core Edit now edits the invoice’s own facts — issued date, due date, terms. Status is not editable there, because changing an invoice’s status is a flow with its own dialog.
  • Fixed: an estimate was showing “Collected — $0.00 of $276.06”, which is invoice wording on a quote nobody owes. That bar is invoice-only now.

7.07 — 7 September 2026

  • Housekeeping: the translation template shipped with the plugin (languages/) had been left behind at an older version, so it no longer matched the text in the plugin. Ten strings that exist in the plugin were missing from the old template, so a translator working from it could not have translated them. It has been regenerated. No code, settings or database change — the plugin behaves exactly as 7.06 did.

7.06 — 6 September 2026

  • Invoices edited after they were sent now say so on the customer’s own page and in the PDF, in the same words as the email: “This replaces the copy sent on …”. An invoice nobody has edited is unchanged.
  • A designed invoice layout can no longer drop a way to pay: the “How to pay” methods and their payment codes are placed under the totals when the layout does not position them itself.
  • Payment codes in the PDF are taken from the full-size image rather than the small one, so they scan off paper.

7.05 — September 2026

  • Invoice links are never tracked. Declares its public /pbj-inv/ route to the CRM’s click tracking (services contract 33, filter pbj_crm_tracking_skip_paths), so a marketing email carrying a pay link keeps it untouched: never rewritten through the click redirect, the token never stored in the CRM’s links table. Declaration only; the database is untouched.
  • The money, in a marketing email. A second field group, The money, is declared to the CRM’s palette as a per-contact one (services contract 35), so a marketing email, a letter or a document — none of which has an invoice behind it — can now offer five fields about the PERSON being written to: {invoice_number} their latest unpaid invoice, {amount_due} what they still owe across all of them, {due_date} when that latest one is due, {pay_link} the link to view and pay it, {late_fee} the late fees on it so far. They are answered on the CRM’s pbj_crm_contact_token_values filter for the contact and, when the contact is a business, for the business’s invoices too — one query per person, memoised, estimates and drafts and voided documents never counted. Somebody who owes nothing gets an empty answer to all five, never “$0.00”, so {amount_due|nothing right now} falls back to the words you wrote. The numbers, the date, the link and the fee are spelled by the same code that spells them in an invoice email, so a figure cannot read one way in one email and another way in the next. The CRM’s own fields always win a name clash, and nothing here is stored: it is read at send time. Guarded end to end — an older CRM never applies the filter, so nothing is offered and nothing changes. The database is untouched.
  • Hotfix — Edit opens the editor again. Pressing Edit on any saved invoice or estimate threw ReferenceError: itemStatus is not defined out of the editor descriptor, the whole invoices section failed to mount, and the panel said “Invoices did not load — Nothing was changed. Try again.”, which reads as a broken LIST and is not one: the list, the record and every REST read were fine. itemStatus() was a helper that has never existed in this file; the two places that called it (the customer chooser’s subtitle and the editor header’s status chip) now read the module’s ONE status vocabulary, STATUS_WORDS through labelStatus() — the same words the list card, the record header and the Status filter already print. No second set of status words was invented. Both calls were on the unconditional path, so this affected every edit of every document. The whole descriptor file was swept for other calls to helpers it does not define; there were none.
  • Hotfix — A payment method can carry a payment code (a QR photo). “Add photos as optional additional ways to pay — Venmo and Cash App QR codes, for example.” This EXTENDS the manual payment methods you already define; it is not a new payment concept and it is not a gateway. Settings → Payment Methods gives every manual method a Payment code column with the same media-library picker the logo uses: choose the QR image once, and it prints beside that method’s name and instructions in all four places a manual method appears — the public tokenized invoice page, the {manual_methods} block a PBJ Templates layout prints, the emailed copy (a plain <img> with a public URL, inline style, no CRM tokens, the method’s own name as its alt text), and the PDF, where it is drawn at 96 pt — 33.9 mm square, above the 30 mm a phone camera reads reliably off paper. Printing the page from a browser pins it to 40 mm for the same reason. No schema change and no migration: manual methods are an array in the plugin’s settings option, so this is one new image_id key beside name and instructions, and a method saved before today simply has no key — which reads as no image, which prints exactly the bytes it printed yesterday (asserted, byte for byte, against the pre-change code). The ATTACHMENT ID is what is stored, never a URL, and it is resolved to a URL (page, email) or to a local file path (PDF) at render time: delete the image from the media library and it vanishes from every invoice, sent ones included, instead of leaving a broken picture behind — and nothing errors. The code rides the invoice’s existing manual_methods_json snapshot the same way the method’s name and instructions always have, through the method id the snapshot already stores. The first-run wizard’s copy of the editor was given the same column, because a wizard that rebuilt the rows without it would have silently wiped every code somebody had set.
  • Hotfix — A re-sent invoice you have edited says it is a revision. Editing a sent invoice and sending it again put a second email in the customer’s inbox that looked identical to the first while carrying different figures. The subject now leads with “Revised” ahead of whatever your own subject template says (“Revised: Invoice INV-0036 from Acme”), the email opens with “This replaces the copy sent on <the original send date> — the amounts and items below are the current ones.”, a text message says “Revised invoice INV-0036” and carries the same sentence, and the invoice’s activity trail records that sentence beside the Resent row. A plain resend of a document nobody has edited is NOT called a revision — the word would stop meaning anything. Nothing was added to the database for this: sent_gmt already holds the date the first copy went out (a resend has always kept it), and the event feed already records edited, sent and resent, so “has it changed since the customer last saw it?” is one query against what is already stored. The public tokenized page and the attached PDF already drew the document’s current rows on every request and are unchanged.

7.04 — September 2026

LAYOUTS – the paper an invoice or an estimate is printed on, designed in PBJ Templates and obeyed by all three renderers (services contract 30). “Rules, not HTML”: the published default layout hands back RULES – paper size (Letter or A4) and margins, whether the top repeats on page 2 and whether the pages are numbered, which line-item columns show and in what order and under what headings, the colours, the font, the logo, the words after the totals – plus its own markup with this plugin’s tokens still in it. The public page prints that markup with the tokens expanded and the FRAGMENTS filled: {items_table}, {totals_table}, {pay_button}, {stamp}, {payments_table}, {notes}, {terms}, {line_notes} and {manual_methods} are blocks this plugin builds itself, per the rules. The carrier email’s {items_table} obeys the same columns and colours, and the wrapper takes the layout’s accent, logo and font. The PDF keeps its own writer and obeys the rules: the page box, the margin, a compact repeat of the top on page 2, page numbers on or off, the columns in order at fixed widths with the per-line DETAIL under the description (drawn for the first time), the ink/muted/line colours, the letterhead logo resolved to a local upload, the closing paragraphs and the pay-button wording. Nine plain tokens are added to the invoice_email palette ({document_title}, {customer_address}, {issue_date}, {status_word}, {business_email}, {business_phone}, {business_address}, {late_fee}, {terms_text}) and filled on every send. Invoicing also declares who uses its layouts – every invoice, every estimate, active recurring billing – and offers your 24 most recent documents as samples with your longest one preselected, so “Check it on paper” draws a real invoice. Money is never recomputed: every figure is the stored one, and the only computed cell on the page, tax per LINE, is display-only and written nowhere. All guarded: no PBJ Templates, an older CRM, or no published default layout and every document prints byte for byte what 7.03 printed. Three fixes ride with it. (1) Attaching the PDF to an email could fatal anywhere outside the website admin – wp_tempnam() lives in wp-admin/includes/file.php, which a REST or cron send never loads – so a scheduled reminder or a send from the portal died where the same send from wp-admin worked; latent since the attachment option shipped. (2) The attached PDF now obeys the layout exactly as the page and the download do, rather than being the one copy drawn the old way. (3) {terms_text} reads the DOCUMENT’s own terms first (its first line), and only then the default-terms setting, so an invoice that says something different about its terms prints what it says. Proven both ways: with the layout unpublished, the page and the PDF of a 14-line invoice, an estimate and a recurring bill are identical to the same three documents with PBJ Templates switched off, and byte for byte what 7.03 draws but for the stylesheet’s cache-busting version number. DB stays 7.

7.03 — September 2026

Invoices finally tells the CRM its fields: the invoice_email token context (customer name, their business, number, total, balance, due date, pay link, business name, the lines as a table) is declared to the CRM’s palette, so an invoice notice or layout in PBJ Templates offers real fields. The five message types (invoice, estimate, reminder, receipt, late fee) are declared to the notice registry seeded with the shipped words, and template() asks PBJ_CRM_Services::notice_for() first — a published designed notice is sent as the finished document it is (tokens swept, {items_table} placed, your note and signature before </body>), otherwise today’s text path runs unchanged. The public invoice / estimate page shows PBJ Templates’ portal notices at the top. All guarded. DB stays 7.

7.02 — September 2026

An invoice, receipt, reminder or late-fee email now carries the sender’s DESIGNED signature from PBJ Templates when they have one, under the message and above the document footer — the CRM’s one seam (services contract 27, filter pbj_crm_signature, context invoice_email), asked with a method_exists() guard so a site without that module, or on an older CRM, sends exactly what it sends today. The signer is whoever pressed Send, else the invoice’s agent, else whoever created it. Nothing else changes; DB stays 7.

7.01 — 4 September 2026

An invoice is Draft, Unpaid, Partly paid, Paid or Voided – and nothing else. The stored sent, viewed and overdue rows all read Unpaid and are mapped at query time, so no invoice data moves; whether an invoice is LATE stays its own separate badge. Estimates and Recurring keep their own vocabularies and no longer borrow the invoice one.

7.0.0 — 4 September 2026

7.0.0 — THE SUITE MAJOR, requiring PBJ CRM 7.0.0. One equal version across the suite. SCHEMA CHANGE: DB 6 to 7 drops the no-op per-invoice reminders_enabled and late_fees_enabled columns. They stopped deciding anything in 1.44.0, when per-document payment chasing was removed — automatic reminders and late fees are SITE settings and were already the only thing any reader consulted — so nothing changes on screen and no invoice data moves. The migration drops one column per statement (a combined ALTER would let a refusal on the second undo the first), verifies BOTH columns are gone before it stamps the version, and heals a half-finished drop on a later request. A PUT that still names either key is refused with the same message it has been given since 1.44.0.

Full release notes: PBJ CRM Suite 7.0.0.

1.44.0 — 2 September 2026

Empty invoice, estimate, recurring and money-owed lists now show a short line drawn with the CRM’s shared empty-state frame, so they match every other empty screen in the portal. No database change.

1.43.1 — 31 August 2026

Invoice lists now load every returned invoice’s line items in one ordered query, and global search resolves company/contact names in two published CRM batch reads. Payloads, item order, company-name precedence, permissions, and database schema are unchanged.

1.43.0 — 30 August 2026

  • A verified payment can no longer be lost to a momentary failure. If recording a payment or refund fails mid-processing, the gateway is now told to retry — instead of being told all is well — and the retried delivery picks the work back up and completes it, exactly once, never twice.
  • A refund that arrives before its payment is no longer dropped. It is acknowledged, held, and reconciled automatically the moment the matching payment is recorded; the daily tick also retries, and an unmatched refund becomes a terminal audit entry after 7 days. Adds one column to the webhook log (database version 6 — the update runs itself and stamps only after verifying).
  • Signature failures and malformed notifications behave exactly as before, and ordinary payment-then-refund processing is unchanged.

1.42.0 — 29 August 2026

  • Invoicing now appears on the CRM’s new “Who can do what” screen – eight rows covering raising and sending an invoice, saving a line for yourself, putting one into the shared price list, recurring billing, voiding, money owed, how an invoice looks, and reminders and late fees.
  • Two rows carry a warning rather than a tidy answer, deliberately. Voiding an invoice and reading money owed both still follow being able to work on that invoice, while the decision of 28 August puts them higher. The screen says so on the row instead of showing the decision as though it had already happened – a table that told you the wrong thing confidently would be worse than no table.
  • Nothing about who can do what has changed in this release.

1.41.0 — 29 August 2026

  • Reminders & late fees are on the front end. Settings > Invoice reminders & late fees now opens in the CRM: the schedule, the grace period, the fee, the repeat, the cap and the “tell the customer” switch, with the same plain-English summary underneath.
  • The warning that nothing can send until your business name is filled in is shown here too, where reminders are switched on – not left to a log nobody reads.
  • Amounts are still typed in dollars and stored in cents, and every limit is the same one the website admin applies. Editing from a phone cannot produce a fee the website admin would not have allowed.
  • The complete screen stays in the website admin as well, unchanged.
  • Invoices can now have their own “Who sees what” setting. A CRM owner can set invoices to open or scoped separately from everything else, and it applies to the invoice list, estimates, “Money owed” and every total. Nothing changes until they set one, and the person a document belongs to always keeps it.

1.40.0 — 28 August 2026

  • SAVED LINE ITEMS ARE PERSONAL FIRST (Access Ladder 23.4). A line you save is YOURS until a manager puts it into everybody’s price list. Before this, anything anybody saved went straight into the shared list for the whole site.
  • DB 4 -> 5: one new column, saved_items.shared. Its DEFAULT is 1 on purpose — every line that already existed is already in everybody’s list, and a default of 0 would have quietly taken all of them away on update. New rows are written 0 by the writer, so the default serves the migration and the writer serves the policy.
  • A manager sees every personal line, because a manager who cannot see a line has no way to promote it. This is strictly a NARROWING for the employee rung and leaves the manager rung exactly where it was.
  • The scope is applied in SQL, so the row cap still caps what this viewer can see rather than capping the table and hiding most of what came back.
  • On a site where the new column has not landed, the list behaves exactly as it did before 1.40.0 — the safe degrade, checked against the database rather than against a stored version number.
  • Refusals now come from the CRM’s own refusal seam where the hub is new enough to build one, and fall back to this plugin’s own sentence where it is not, so the minimum-CRM floor does not move.

1.39.1 — 28 August 2026

  • Translation template regenerated. No change to how anything works.

1.39.0 — 28 August 2026

  • A line can carry its own description. Each row on an invoice or estimate gets a DESC line beneath the figures, so a charge can explain itself without pushing the explanation down into the notes block. Database version 4.
  • The due date honours a setting of zero. A site configured for 0 days was still getting 30, because a zero was being treated as “nothing set”. Fixed here and on the recurring schedule’s own due-in-days, which had the identical fault.
  • Linked records and Activity now appear on an invoice. The panel existed but was reading keys the server does not send, so it was empty on every document ever opened. An invoice raised from a ticket or a visit now shows that link, and the trail of what happened to it.

1.38.0 — 28 August 2026

  • The estimate and invoice editor is rebuilt to one layout. The document down the middle; totals, delivery, notes and terms beside it, or below it on a phone. On a new document an Estimate/Invoice switch changes what you are writing in place. Tax rate, deposit, reminders, late fees and manual payment methods are settings now, decided once — existing documents keep exactly the values they had.
  • A business can be a recipient. An invoice for a company addressed to that company is the ordinary case, and the only way to say it used to be leaving the recipient list empty. Any other business is still refused.
  • The PDF gives your customer a way to pay. It listed the manual methods and nothing else, so somebody holding the download could not reach card checkout at all.
  • The Send window no longer asks for a subject it was throwing away, and it names the address your customer will actually see the email from.
  • A line item with no description reads “Untitled item” instead of being blank.
  • Overdue documents carry an orange dot, and one past the late-fee point a red one, on every list they appear in.
  • Creating or editing a document works again after 1.35.x — the editor was asking for a list at an address that only ever accepted saves, and one refusal took the whole screen.
  • Merging two contacts now moves invoices and recurring profiles onto the survivor.

1.34.0 — 24 August 2026

  • Invoice, estimate, recurring and Money Owed lists now use CRM-owned cards, readers, footer actions and saved workspaces.
  • No-rail readers use the full remaining width, and the Money Owed explainer can be dismissed per signed-in user.
  • Invoice due dates and authoritative recurring next-run dates contribute to the shared Calendar registry.
  • Scoped invoice and recurring work can appear in the CRM-owned Open Work section without module-owned card markup.

1.33.0 — 24 August 2026

  • Invoices, estimates, recurring profiles and Money Owed now use CRM-owned cards, readers and saved workspaces.
  • Readers without a side rail use the full available width.
  • The Money Owed explanation is now dismissible per user.
  • Active recurring profiles contribute their authoritative next-run dates to the shared Calendar.

1.32.0

Your invoice theme and your email templates are now drawn by the CRM inside the portal, in the same look as the rest of the suite — rather than on a screen of their own that looked like a different product.

Nothing about what they do has changed, and nothing you had set has been moved or reset. Only where you find them, and what they look like when you get there.

1.31.0

See late money at a glance. An invoice past its due date shows an orange circle, and one past the late-fee point (a fee has been added, or the grace period has run out) shows a red circle — on the invoice list, the invoice itself and the Money owed to you screen.

1.30.0

Add Work on a person or business profile can raise an invoice directly, for people with invoice access. No database change.

1.29.0

One shared answer to “has this ticket or visit been invoiced yet?” Other PBJ modules can now show View invoice instead of Create invoice when one already exists. No database change.

1.28.0

Invoice line items are usable on a phone. Every line is a full-width labeled card for description, quantity, price, tax, amount, reuse and remove; desktop remains a table. Issue and due dates stay inside the card and retain date-only behavior.

Direct company links now show the authoritative business name, including a business with no contacts. Permitted agents get Find invoices and Create invoice in the mobile menu, plus Create/View invoice actions from completed tickets and visits.

1.27.0

Documents inherit the communication method of the ticket or visit they came from. Email keeps the established invoice mailer, text sends a concise message with the protected document link, and phone starts click-to-call. If no usable origin exists, the agent chooses. No database or minimum-CRM change.

1.26.0

Invoice reporting now lives on the CRM’s unified Reports screen. Invoicing registers its existing Money owed report only while the module is installed, so reports stay useful without showing unavailable modules.

Requires PBJ CRM 1.46.0 or newer. No database change.

1.25.0

New invoices and repeat bills now use the due terms set in admin. A fourteen-day setting produces fourteen days, and an intentional zero means due today; the editor no longer silently falls back to thirty days.

Current invoices now appear in CRM Everything. They are visible on the customer or business record and on the creating agent’s profile, including through that agent’s manager and owner visibility ladder. No database change.

1.24.0

The “Invoices” and “Estimates” headings no longer repeat the tab directly above them.

1.23.0

An invoice or an estimate is now something you can attach things to — tasks, notes and files. The chase-up list for a bill can sit on the bill itself.

The document’s own number is used wherever an attached item says where it lives, never one worked out from its id. Invoices and estimates are numbered separately, so a worked-out reference would disagree with the document you have already sent.

1.22.0

Fixed: the “Pay by card” button your customers see is readable again. On the invoice page your customer opens, that button was invisible until you moved the mouse over it. It now reads properly the moment the page opens. The Decline button on estimates had exactly the same fault and is fixed too. Nothing was ever broken about paying — the button worked all along, you just could not read it.

On your own invoice screen the Edit button now appears once, at the top, instead of twice.

A print button, and a tidier printed invoice.

1.21.0

An assistant can now put lines on an invoice. Before this it could only create an empty one, which totalled nothing and had no way of getting anything onto it. It can now add a line, change a line and take a line off. The arithmetic has not moved: the same multiplication and the same rounding happen in the same one place they always have.

It can also record a payment you have already been given — cash, cheque, bank transfer, or whatever else you have set up by hand. There is deliberately no way for an assistant to take a card payment, and no way for it to give money back; a payment for a negative amount is refused. Repeat bills and the money-owed list can both be read. One thing worth knowing: an invoice an assistant makes stays a draft, because it has no way to move a document on to the next stage.

Money safety: a quantity written with a comma is now refused. On the screen “1,500” sensibly means fifteen hundred. Sent by an assistant, or pasted out of a spreadsheet, “1,5” usually means one and a half — and it was being read as fifteen, a tenfold overcharge, without a word said. An assistant is now told to send a plain number with a dot, for example “1.5”. Nothing about typing quantities on the invoice screen has changed.

1.20.0

“What has changed since” now gives an honest total. Ask an assistant which invoices or estimates have changed since a date and the number it reports is the number that really did change, and it agrees with the documents listed beside it. It used to hand back the total for everything, so the count stopped short of the truth. An assistant asking what has changed now gets the complete answer.

1.19.0

Invoices, estimates and recurring billing are available to the CRM’s new assistant connector (Apps & Assistants) — always as you, seeing only your own slice. Requires PBJ CRM 1.29.0 or newer. Nothing else changed.

1.18.0

The pay button is readable before you touch it. The label colour is now chosen by real contrast arithmetic against your accent colour — on the page, the PDF and the email alike. And “How to pay” says the right thing: with an online payment button on the page the manual methods heading reads “Additional ways to pay”; with no online option it stays “How to pay”.

1.17.0

Invoices, estimates and recurring billing join the suite’s search — and searching by the customer’s name now really works, on the invoice list and in the header search.

1.16.0

The invoicing round-out. Six things, and a database update.

Raise an invoice from a ticket. Any ticket in PBJ Helpdesk 2.15.0 or newer — open or closed — now carries a “Create an invoice” button. Billing a job you only think about after closing the ticket is the normal way round, and until now nothing on a ticket led to an invoice at all.

A savable description under the line items. Write the paragraph that explains what the work was, then press “Save for reuse” and it joins a list you can pick from next time. It is separate from the Notes block, which stays your closing message at the bottom.

A business can be the only recipient. If a business has its own email address in the CRM you no longer have to name a person at it — a company-only invoice is now a normal document rather than something the editor blocks. If there is neither a ticked person nor an address on the business, the save still refuses, and it now tells you both ways to fix it. Recurring profiles follow the same rule.

Standard terms. There is a general-purpose terms template and a “Use the standard terms” button that drops it in as ordinary editable text. The terms box also shows your site-wide defaults as greyed-out placeholder text, so you can finally see what an invoice will say when you leave the box empty instead of guessing.

Re-open a closed invoice. Managers and above get a Re-open button on a paid invoice. It asks for a reason, will not go ahead without one, and keeps the reason with the invoice. Note what re-opening now does: the invoice stays open. It will not put itself back to Paid on the next nightly run — a person decides when it closes again, so a refund or a query cannot be quietly erased.

Database update. Two new columns, applied automatically. It is checked before it is recorded as done, a site left half-finished by an earlier attempt repairs itself on the next page load, and a host that refuses the change is retried a bounded number of times and then told about on screen — instead of being retried on every page view for ever.

1.15.0

The customer box on invoices and estimates can now add somebody who is not in your list yet. Type the name, and if nothing matches, press “+ Add a new person” (or “+ Add a new business”) and fill in the name, email and phone right there — no trip to the CRM in the middle of writing an invoice. Nothing is ever added until you press Save on that little form.

The new box comes from PBJ CRM 1.22.0. With an older CRM, the customer box looks and works exactly as it did before. No database changes.

1.14.0

If you charge percentage late fees, please read this one. A late fee could be applied more than once to the same invoice — and once it started, it repeated every night. It happened when the record of the charge failed to save while the charge itself went through, so the next run could not tell the fee had already been applied. Charges are now recorded first and checked before any money is added. If you use late fees, it is worth looking over your overdue and recently paid invoices and crediting back anything that was charged twice.

A second fee problem is fixed with it: an invoice paid while the nightly run was working through the list could still be charged, which reopened a settled invoice and emailed the customer about it. Every invoice is now re-checked immediately before it is charged.

Percentage late fees are also now applied at the same precision they are saved and previewed at. A 1.2345% fee on a $10,000 invoice charged $123.50 and now charges $123.45 — the figure the settings screen always showed. Nothing you have saved changes meaning.

Also: every money amount is now produced in one place, so the same total can no longer be spelled two ways on the screen and the PDF; changing a deposit between a flat amount and a percentage without giving a new figure is refused rather than silently misread; and the plugin checks that PBJ CRM is new enough, not merely installed. No database change.

1.13.0

Your invoice email templates and your reminder and late-fee settings now appear on PBJ CRM’s Templates & Notifications tab, next to every other add-on’s. Nothing about how they work has changed — only where you find them. Behind the scenes, the “never cache this page” rule now comes from PBJ CRM instead of a copy kept here, and your invoice page, its PDF and the not-found page all send the full set of no-cache instructions on every route rather than only on the routes that happened to add them. No database change.

1.12.0

Two important fixes found in review. Monthly and yearly recurring invoices no longer drift at month end: a profile billed on the 31st used to slide forward and stay slid, and one billed on the 28th or 30th could quietly become a month-end profile. The day you chose is now remembered and kept — the 31st clamps to the short month and comes back to the 31st, while the 30th stays the 30th. Separately, a flood of fake payment notifications can no longer stop genuine ones from being recorded. Also: a bare number typed as an invoice date is read as the date it says instead of becoming a 1970 date.

1.11.0

Saved line items: save the lines you use often and add them to any invoice, estimate or recurring template with one pick — nothing saves as a side effect, and every added line stays editable.

1.8.0–1.10.1

Hosted checkout and signed webhooks for Square, PayPal and Stripe (payments land even if the tab closes; receipts sent automatically); the daily jobs really run — overdue sweep, reminders, late fees, recurring invoices — with a “Run the daily jobs now” button and a dead-cron warning; full mobile pass.

1.4.0–1.7.0

Settings moved inside PBJ CRM; payment credentials live once on the CRM’s Connected accounts screen; invoice email sends through the CRM’s mailboxes; screens follow the CRM theme.

1.0.0–1.3.0

The foundation: invoices and estimates bound to CRM contacts and businesses, whole-cent money math, the tokenized public invoice page with PDF, invoice themes, “Jane at Acme” documents, and the “Money owed to you” screen with aging buckets and CSV.

Latest Articles