The prepaid usage PDF buttons work again
If you have tried to download a prepaid usage report as a PDF since July and got "No PDF URL returned", you were not doing anything wrong and it was not a temporary glitch. Both buttons — the one in each row's Actions column and Generate All PDFs — had been broken the entire time, for every client, on every attempt.
The awkward part is how quietly it broke. The server was generating your PDF perfectly well and reporting success. The page was reading the reply in a format the server had stopped sending back in July, found nothing where it expected the file, and showed you an error. So the request succeeded and you still got nothing, which is why this never showed up as a failure anywhere we were watching.
Both buttons work now.
Generate All PDFs gives you a list instead of a pile of pop-ups
Generate All PDFs used to try to open every report in its own new window. Browsers block that after the first one, so even once the underlying bug was fixed you would have got one report and a blocked-pop-ups warning.
It now generates them and gives you a list of links to open as you need them.
If your browser blocks a download, we now say so
Related: when a browser blocked the pop-up, the app recorded that as a success. You got no file and no explanation, which looked exactly like the bug above.
A blocked download is now reported as a failure, with a message telling you what happened, and errors on an individual row are actually shown to you rather than swallowed.
One permission change to know about
Prepaid usage PDFs now require the Owner or Admin role.
The prepaid usage report page has always been restricted to owners and admins, because it contains financial detail not everyone should see. The PDF download behind it was not — it only checked that you were a member of the organization. Anyone who could reach the address directly could pull a report the page itself would not have shown them.
The download now applies the same rule as the page it belongs to.
What this means for you: if someone on your team has been downloading these PDFs and is not an Owner or Admin, they will stop being able to. That is the intended behaviour, not a new bug — but we would rather you heard it here than discovered it on a Monday morning. Change their role if they need the access.
And a cache mix-up, fixed before it could reach anyone
While fixing the above we found that stored reports were filed under a name that left out which period they covered, so a report for one period could have been served in place of another's.
Nobody received a wrong PDF from this, for the simple reason that the buttons were completely dead — no report was ever delivered, correct or otherwise. Fixing the buttons is what would have made it reachable, which is why both fixes ship together rather than the visible one first.
Claude connection: renewals can point at their quote
If you use the Claude connection, a renewal can now be linked to the quote it relates to, and the links can be read back.
You can record that a renewal came from a particular quote — useful when you are entering an existing contract and want the history to show where it originated — or attach a quote as the renewal or amendment currently in flight. You can list the quotes linked to a renewal, and unlink one if you picked the wrong kind of link.
Previously you could ask Claude to attach a quote to a renewal and it would cheerfully report success while saving nothing at all. That is fixed, and it is now a real relationship the rest of the app can see rather than a stored number that nothing checked.
Errors that tell you what is actually wrong
Linking the same quote twice, or recording a second originating quote, used to come back as "try again shortly" — the one answer that invites Claude to send the identical request again, forever, when the problem was never temporary.
Those cases now explain the actual conflict and name the link that already exists, so Claude can tell you what to do instead of retrying.
Behind the scenes
- Our background jobs — invoicing runs, integration syncs, scheduled maintenance — moved to a newer runtime ahead of the old one being retired by the provider. No change you should notice; this is the kind of maintenance that only becomes visible if it is left too late.
- Continued groundwork on passkeys (signing in with a fingerprint, face, or security key instead of a password). This release fixes a batch of problems found in testing: keyboard and screen-reader users getting no feedback, buttons that stayed stuck after a cancelled prompt, the sign-in button making the login page jump as it loaded, and unhelpful copy when verification failed. Passkeys are not switched on yet and there is nothing to see in the app — we will say so clearly in a release note when they are ready.
- General reliability and stability improvements.