deadlinescan

QuickBooks Online reports look wrong since Sept 1, 2026

Columns landing in the wrong place. Blank cells where you used to read zeros. Account hierarchies at a different depth. A report that returns nothing at all, or is simply gone. The API is answering; the shape of the answer changed.

QBO: the Reports API serves only modernized v2 responses since Sept 1, 2026; webhooks are CloudEvents since Jul 31, 2026.

Why

Intuit's Reports API modernization had a completion deadline of August 31, 2026 — extended from an earlier date — after which all responses are served by the modernized service only. That means the cutover took effect on September 1, 2026, and it applies whether or not an integration was updated for it.

Two different things break, and it matters which one you have:

Reports named in the documented set include Profit and Loss, Balance Sheet, Cash Flow, General Ledger and Trial Balance. Reports reported as dropped include Transaction Detail, Unpaid Bills, Invoice List and Customer Contact List; coverage of the cutover also lists Sales by Customer Detail, 1099 Transaction Detail, Bills and Applied Payments, Check Detail, Open Purchase Orders and Balance Sheet Detail among those at risk. Check your own report names against Intuit's current documented list rather than against this page.

What to do right now

  1. Re-test the parsing against a live v2 response for every report you call. Not against a fixture recorded before September 2026 — the fixture is the thing that is now wrong.
  2. Stop reading by position. Column and row positions moved; read by column identity, and treat a blank cell as zero explicitly rather than letting it parse as one, or as null, by accident.
  3. For a dropped report, rebuild it from the underlying entities. There is no equivalent endpoint to migrate to. The realistic path is to reconstruct the report from invoices, bills, transactions and payments through the standard Accounting API's query endpoints.
  4. Check the SDK version you have pinned. Older QuickBooks SDK versions parse against the legacy shapes and will misparse or silently drop data against current API responses. For the .NET, Node and Python SDKs, a version bump — not a rewrite — is usually the fix for the SDK half of this.

Then scan the code

DeadlineScan is a free, MIT-licensed command-line scanner. It flags QuickBooks Reports API call sites and splits them the way the cutover does: a call to a documented survivor is reported as a response-shape change to re-test, and a call to a report name that is not among the documented survivors is reported as a gap with no equivalent call to migrate to. It also flags QuickBooks SDK references so you can check the pinned version.

deadlinescan scan ./my-repo

Get the scanner: email hello@deadlinescan.com and you'll get the source and a Windows binary by reply — the public repository is being prepared.

A finding count of zero means no affected call sites were FOUND — not that you're unaffected.

Read that line literally here, because the QuickBooks rules carry a specific caveat: they have never been run against a real QuickBooks codebase. The five repositories in the published validation audit are all EWS, so zero QuickBooks findings across that corpus is evidence that the rules do not fire on unrelated code — not evidence that they fire correctly on yours. The validation numbers, in full.

Sources

Related