Windows update
MYOB AccountRight stopped printing for many Australian businesses after the August 2026 .NET security update, which made Windows reject fifteen stock fonts including Calibri while preparing a document for print. The printer is not at fault. Changing affected templates to Calibri Light fixes it permanently and keeps the security update in place.
A Microsoft security update broke font handling inside Windows itself. The symptom looks exactly like a printer fault, which is why it costs practices a day before anyone finds it.
Last updated
What broke
MYOB AccountRight is doing exactly what it has always done.
MYOB AccountRight builds its printed output through Windows Presentation Foundation. Part of building a printed document is subsetting each font — cutting the font file down to just the characters the page needs. The August 2026 .NET security update tightened how strictly that code validates a font file before using it, and fifteen fonts that ship with Windows now fail the check. Calibri is one of them.
When a font fails, the code does not skip it or substitute another. It abandons the whole document. Nothing is sent to the printer, so the job never appears in the queue and there is nothing to troubleshoot at the printer end.
System.IO.FileFormatException The file 'C:\Windows\Fonts\calibri.ttf' does not conform to the expected file format specification.
Often there is no error at all — the progress dialog simply sits on “Please wait…” indefinitely, because the failure happens inside the render and the dialog is never told to close.
The technical cause: the affected fonts carry a legacy kern table larger than 65,535 bytes. The header field recording that table’s length can only count to 65,535, so it wraps and reports a value that cannot be correct. The previous code never checked. The hardened code does, and rejects the font outright. Microsoft has confirmed this as a regression; it is tracked publicly as issue #11834 in the dotnet/wpf repository.
Triage
One test separates this from a genuine printer fault.
Print one line from Word or Notepad to the same printer, from the same machine, as the same user. If that works and MYOB does not, this is your fault.
Most machines took the update between 11 and 13 August 2026. Printing that worked the week before and stopped after patching lines up exactly.
It fails identically, because emailing an invoice uses the same rendering path. That is confirmation of the diagnosis, not a second problem.
Print preview never touches the broken code. A clean preview tells you nothing about whether the document will print.
Proof
One command settles whether a machine is affected.
Run this from an elevated PowerShell prompt:
powershell -Command "Get-ChildItem 'C:\Windows\Microsoft.NET\assembly' -Recurse -Filter PresentationCore.dll -ErrorAction SilentlyContinue | ForEach-Object { $_.VersionInfo.FileVersion }"4.8.9344.0 means the machine has the update that causes the fault. 4.8.9340.0 or lower means it does not, and your printing problem is something else. Several results is normal — Windows keeps more than one copy, and any single result at 4.8.9344.0 means affected.
Check the version rather than the KB number. The update ships under a different KB on every Windows version — KB5120708 on Windows 11 25H2, KB5120705 on Server 2022, and different numbers again across the Windows 10 and Server builds. Auditing a fleet by KB number will report machines as clean when they are not. The file version is identical on every platform.
Scope
Cambria Regular is fine while its bold and italic are not.
That a form can print until someone bolds a heading is why this is hard to diagnose from a helpdesk ticket. The same template, on the same machine, behaves differently depending on which weight of Cambria a user applied.
The fix
It keeps the security update in place and survives every future update.
Change every affected font in your templates to Calibri Light. No registry edits, no policy changes, no exclusions to maintain — and because nothing on your side depends on Microsoft shipping a fix, next month’s rollup cannot reintroduce the problem.
In MYOB AccountRight, start by working out which forms are actually in use: a customer card under Selling Details › Printed Form, and Print/Email Invoices › Advanced Filters. Then Setup › Customise Forms, select the type, highlight the form and choose Customise. Use Save Form As to keep a backup, then edit the original in place — customer cards point at it by name, so a renamed form quietly stops being used.
Work band by band. Header, body and footer do not select together, so “select all” only ever catches the band you are in. Double-click into the data table separately: the column headings carry different font settings from the column contents, and this is the step most often missed. Then check the ABN block, amount-in-words line, tax summary, payment terms, free-text boxes and page numbers individually. Reports are separate again — display the report, then the Insert & Modify tab. Forms live inside the company file, so multiple company files mean repeating the work per file.
It is all-or-nothing. A single text box left on Calibri anywhere on the form stops the entire document rendering, exactly as before. There is no partial success and no useful error pointing at the object you missed. Always verify with a real print, never a preview.
Dead ends
Every one of these is a normal first instinct, and none of them help.
The document never reaches the driver. A new driver receives exactly as much as the old one did, which is nothing.
The queue is empty because nothing was ever submitted. Restarting the spooler restarts a service that is working correctly.
Same reason, at considerably greater cost. This is the one that consumes a day.
The fault is in a Windows component underneath it. A reinstall returns you to the same position with the afternoon gone.
If you manage a fleet
Clients will report this as a printer fault, not a software fault.
No, in almost every case. If Word prints to that same printer and MYOB does not, the printer is proven to be working — the document is failing before anything is sent to it. Replacing the printer or the driver changes nothing, which is worth establishing before anyone raises a purchase order.
Preview and on-screen rendering use a different path that never subsets fonts. The broken code only runs at the export step, which is why an invoice looks flawless right up until you press print. Always confirm a fix with a real print rather than a preview.
No. Browser-based software prints through the browser, which does not use the affected component, and Word, Excel and Outlook are unaffected for the same reason. Exposure is limited to desktop software built on .NET and WPF — MYOB AccountRight, Wolters Kluwer CCH and Crystal Reports–based packages among them.
It restores printing, but it re-opens two security vulnerabilities the update was released to close, and .NET rollups are cumulative so next month's update brings the same code back. Treat it as a stopgap with a diarised date to reverse it, not a fix, and record it as a deliberate decision rather than an undocumented change.
One object was missed — it only takes one. The usual culprit is the data table, whose column headings carry separate font settings from the column contents. After that, check the ABN block, amount-in-words line, tax summary, payment terms, free-text boxes and page numbers, each of which is its own object.
Microsoft has confirmed the fault as a regression and given it top priority, but as at 21 August 2026 no corrected build has shipped and no date has been published. That uncertainty is the argument for changing the fonts: it takes about an hour and the release date stops mattering to you.
Get help
Send us the symptom and we will tell you whether it is this fault, what it will take to clear, and what to do about the rest of your machines.