fixmation.Get my quote
Integrations15 min readPublished September 2026

Your QuickBooks report still works, and it changed shape

Intuit moved the Reports API onto the service behind the modern report view. The URL and the request body are unchanged, the response is still valid JSON, and zeroes come back as blank cells while rows move around. Whether it has reached your company is something you test, not something you read.

A break that arrives as a spreadsheet

The month closes, the export runs, the numbers land in the sheet. Nothing errors. A total is off, or a column is blank where it used to be zero, or a subtotal has walked one row down and taken a formula with it.

This is the quietest kind of failure in any automation, and accounting is where it does the most damage, because the output looks like a report and reports are read rather than tested. Intuit has been migrating the QuickBooks Online Reports API onto a new backend, and it says so plainly:

Our APIs will soon be updated to use the same service that powers the modern view of the reports. While there is no need to make changes to the API request URL and body, there are some differences expected in the API responses. This applies to all the reports APIs currently available on our API reference.

Same URL, same body, and for a lot of reports a differently shaped answer. Intuit's own wording is "some differences expected", and there are reports whose output comes back unchanged. Nothing in any of this produces an error in a monitoring dashboard.

What is the actual deadline?

31 August 2026, and it moved once before that:

You must complete all required changes by August 31, 2026. After this date, all responses will be served by the modernized service only.

  • same post

Editor's Note: [...] Deadline for the migration was updated from June 30, 2026 to August 31, 2026 on 6/26/26.

  • same post

Worth being precise here, because the shorthand version of this change going around is "from 1 September everything is on the new service", and the evidence does not support it. What Intuit published is a deadline for you to be ready by, not a promise about the hour your company gets switched.

So has it happened to your account or not?

That is the awkward part, and the honest answer is that you cannot tell by reading anything.

A developer asked the direct question at the end of August, including which time zone the deadline used. Intuit's answer was that a support ticket had been created. On 1 September the same developer came back:

today is September 1st, and we can still see that the Modern Report Engine has not been enabled yet. Could you please provide an update on the rollout status and any latest information available?

Intuit Developer Support replied:

the Modern Report Engine enablement is still pending with the internal team, and an update will be posted on the original ticket as soon as one is available.

  • Intuit Developer Support, same thread

Elsewhere, developers describe the rollout as running in groups, with one naming a ramp window for a particular report. Intuit has not published that schedule.

The practical consequence is worth stating on its own. The same integration can be broken for one of your clients and fine for another on the same day, with no difference in your code. If you support several QuickBooks companies, treat this as a per-company condition rather than a date.

Is there a way to tell which engine answered?

There is one, it works, and it is not in the documentation. Developers comparing responses found that the modernized backend sets a header on the response:

text
v3modernResponse: true

It shows up in three separate threads on Intuit's support forum, always written down by developers rather than published by Intuit. In a fourth thread, after the cutover, a developer asked directly whether there is "a supported way to determine which report-service path handled a request". That question went unanswered.

There is also a documented way to see the future on demand. Adding a parameter to the request routes it through the new service:

These changes are available for testing right away. To receive the modernized responses, add a query parameter called "testing_migration" to your API requests. This is a temporary parameter and will route your requests through our modernized service, enabling you to validate your integration prior to the transition.

That is the single most useful thing in this article, with one caveat that has grown since the deadline passed. Run your existing report call twice, once plain and once with the parameter, and compare the two responses field by field.

The caveat is that Intuit now calls the parameter "deprecated and unsupported", and that its meaning flips once your company has been switched. On a company still on the old service, the flag shows you the future. On a company already migrated, the plain call is the new behaviour and the flag is what still shows the old one, which is the position one developer found themselves in after the cutover, further down this page. Either way the comparison tells you something. It is the labels that swap.

Which differences actually break a spreadsheet?

Intuit lists thirteen. Three of them are plain bug fixes. These seven are the ones that change a number or a position without changing a status code:

ChangeWhat Intuit says
Blanks instead of zeroes"In v2, the API will always return an empty string ("")" where v1 "was sometimes 0 and sometimes an empty string"
Rows move"row orders are dynamically generated and index positions will not be the same [...] Do not rely on row index positions"
Deeper nesting"In v2, child accounts are always nested under their parent account, regardless of whether the parent account has a transaction or not"
The Split column emptiesWhere a row has no split account, v1 returned "-Split-" and "In v2, this will be an empty string ("")"
Section rows change typeAn empty enclosing section was typed "Data" in v1 and is typed "Section" in v2
Column titles change case"In v1, ColTitle was sometimes returned in ALL CAPS. In v2, it will always be Title Case"
A year by days is truncatedAsking for a full year by days returned all 365 columns in v1. In v2 "only 200 columns will be returned and the rest would be categorized as 'Others'"

Read that list as a spreadsheet owner rather than as a developer. An empty string where a zero used to be does not sum, does not average, and quietly turns a column of numbers into a column of text in some tools. A row that moved breaks anything keyed on position. Deeper nesting changes indentation, which changes which rows a lookup matches.

The accounting trade press covering the change described the symptoms in almost those terms: columns lining up differently, rows moving, hierarchies looking more nested, labels moving, and zeroes turning into blank cells.

If your finance sheet is built on cell positions rather than on labels, this is the change that finds out. That is the general hazard in treating a spreadsheet as a database, arriving here through the accounting side.

Which reports survive?

Twenty-nine, and only those:

There are 29 reports APIs documented and these are the only reports that will be supported in v2. If your app was accessing other reports via the API, those reports will not be supported in the API any longer.

Undocumented report endpoints have been in use for years, because they worked. One integrator asked about a specific one in March and got a clear answer:

Yes, only the 29 officially documented Reports API endpoints will continue to be supported going forward. Any non-documented reports will stop working after the cutover. If Transaction Detail by Account is not included in the documented list, it will be deprecated, and you'll need to migrate to one of the supported alternatives.

The person who asked pushed back that the report in question "is an incredibly useful report" and asked whether there was any possibility of keeping it. There is no answer to that in the thread.

If somebody built you a bookkeeping automation and it pulls a report you cannot find in Intuit's documentation, that is the first thing to check.

Two parameters worth checking by name

group_by is gone, except where it is not. The original announcement said "The group_by parameter is no longer supported in the API", and a later update to the same post walked part of that back: it stays for TransactionList, TransactionListByCustomer, TransactionListByVendor and TransactionListWithSplits. So the answer depends on which report you call, and the announcement's headline version is wrong for four of them.

qzurl is not supported in v2, because the drill-down link it produced cannot be built the same way any more. Two details make this one likely to bite. Intuit's own reference documentation still described the parameter in September. And six and a half weeks before the migration announcement, Intuit's own best-practices post recommended using it, telling developers to "use the qzurl=true parameter" for drill-down. That post was edited again twenty days before the announcement, and the recommendation stayed in. Following the vendor's advice and following the vendor's deprecation notice are, for a moment here, the same act pointed in two directions.

Where does this land in your automation platform?

Nowhere convenient, which is the reason this hits contractors' work rather than vendor connectors.

n8n has ten QuickBooks resources and no report resource. There is exactly one report call in the node, on the Transaction resource, and it goes to reports/TransactionList. That report is on the supported list and keeps group_by, which is the good news. The node also sends qzurl, defaulting to true, which v2 does not support. And its Simplify option builds each output row by matching column types to values by position, on a shape that assumes every row carries data cells, which is the assumption Intuit's notes explicitly tell you to stop making.

Make has no report module at all. Its QuickBooks app covers invoices, bills, estimates, journal entries, customers and the rest, and reports are reachable only through the generic "Make an API Call" module.

Zapier has no report trigger or action either.

So in all three, "get a report out of QuickBooks" is either one hardcoded report or a hand-built HTTP call with hand-written parsing. The parsing is the thing that breaks, and it belongs to whoever built it. If that person has moved on, what you need first is an inventory of what your automations ask for and what comes back now, which is an afternoon of work and the kind of thing we quote as a Fix.

What is already broken, after the deadline

Two things worth knowing, because they show the shape of this migration rather than a hypothetical.

In June, developers validating early found that the modernized ProfitAndLossDetail came back without the per-transaction amount, and that asking for the amount column explicitly did nothing. One of them reported that the modernized report "SILENTLY IGNORES the amount column key while honoring the string keys requested alongside it". A detail report with no amounts is not a degraded report, it is a blank one. Intuit deployed a fix in July, four weeks later.

Then, after the cutover, on 1 September, another developer reported that ProfitAndLossDetail was returning blank account identifiers on child rows. Intuit Developer Support's reply is the useful part:

Known defect: Child AccountId missing in ProfitAndLossDetail v2. [...] Workaround: Use v1 for child account attribution until the v2 fix is deployed. Totals: Reconcile correctly in v2, so numeric accuracy is unaffected.

"Totals: Reconcile correctly in v2, so numeric accuracy is unaffected" is exactly right and exactly beside the point for anyone whose report splits by account. The sum is fine. The breakdown is empty. A bookkeeper reading that report sees a correct total over a wrong shape, which is the hardest kind of error to catch because the number you would check is the number that agrees.

What to do this week

  1. Find every automation that pulls a QuickBooks report. Scheduled exports to Sheets or Excel, dashboards, the monthly summary somebody built, anything using an HTTP step against reports/.
  2. Run each one twice, once with the testing_migration parameter, and compare the two responses field by field. That is a fifteen-minute check that answers the whole question for one report. Intuit calls the parameter deprecated now, so use it to compare, not to build on.
  3. Check whether the report you call is on the documented list of twenty-nine. If you cannot find its page in Intuit's reference, assume it is going away.
  4. Search your parsing code for row indexes. Anything that reads "row 3" rather than "the row labelled X" is the first thing to break.
  5. Search for zero handling. Sums and averages that assumed a numeric zero will now meet an empty string.
  6. Check every QuickBooks company separately if you serve more than one, because the switch does not appear to arrive everywhere at once. This is the case that needs a view across all your client accounts at once, not a check on the one client who complained.
  7. Reconcile one full month by hand after the switch reaches you. Not the totals, which are the part Intuit says is fine, but the breakdown.

When this is a job to hand over

If you have one report going into one sheet, run the comparison yourself. The parameter is the whole trick, and you will know within the hour.

It becomes a job when several clients are on different sides of the rollout, when the parsing was written by somebody who has moved on, when the report feeds something a person signs, or when the export is a hand-built HTTP call nobody has read closely since it was built. The useful thing about all four is that they are countable. List the reports, list the companies, and the size of the job is known before anyone starts, which is how a fix gets a price up front.

Two months from now this will look like an accounting problem rather than a software one. Somebody will notice that a quarter does not tie out, and the explanation will turn out to be a change nobody sent to the person who depends on it, made in a response that returned 200 every single time.

Sources

  • Upcoming changes to Reports APIs - Intuit Developer, published 30 March 2026, updated 26 June 2026, read 7 September 2026. The move to the service behind the modern report view with unchanged URL and body, the thirteen documented response differences, the testing_migration parameter, the 31 August 2026 deadline and its move from 30 June, the removal of group_by and its later partial reinstatement, qzurl being unsupported, and the statement that only the 29 documented reports survive.
  • QuickBooks Online Reports API - best practices and troubleshooting - Intuit Developer, published 13 February 2026, read 7 September 2026. The recommendation to use qzurl=true for drill-down, six weeks before the migration announcement said it would not be supported.
  • Reports API changes - deprecation of non-documented reports - Intuit Developer Support forum, March 2026, read 7 September 2026. Intuit Developer Support confirming that only the 29 documented endpoints survive and that undocumented reports stop working after the cutover.
  • QuickBooks v2 modern reports rollout timeline and migration plan - Intuit Developer Support forum, August to September 2026, read 7 September 2026. A developer asking whether the deadline is firm and in which time zone, reporting on 1 September that the engine was not enabled, and Intuit replying that enablement was still pending.
  • Reports API v2 ProfitAndLossDetail omits child AccountId values after the August 31 cutover - Intuit Developer Support forum, September 2026, read 7 September 2026. The known defect on child account identifiers, the workaround of using v1 for that attribution, and the note that totals reconcile.
  • Modernized ProfitAndLossDetail no longer returns the Amount column - Intuit Developer Support forum, June 2026, read 7 September 2026. The missing per-transaction amount under testing_migration, the explicit column request being dropped without an error, and the later confirmation that it was fixed.
  • Modernized ProfitAndLossDetail omits the Amount column and line-item amounts are missing - Intuit Developer Support forum, June to July 2026, read 7 September 2026. The side-by-side comparison of legacy and modernized responses, the amount column key being silently ignored while the others were honoured, the same key working on another report, and Intuit's confirmation in July that the fix had been deployed.
  • n8n-io/n8n - n8n source, read 7 September 2026. The QuickBooks node's ten resources with no report resource, the single report call to reports/TransactionList, the qzurl option defaulting to true, the group_by option, and the Simplify helper mapping column types to values by position.
  • QuickBooks modules - Make apps documentation, updated 4 September 2026, read 7 September 2026. The full module list, which contains no report module, and the generic API call module.
  • How to get started with QuickBooks Online on Zapier - Zapier Help Center, updated 10 August 2026, read 7 September 2026. The full trigger and action list, which contains no report step, and the QuickBooks Online rate limits.
  • One accounting trade-press report on the cutover, 28 August 2026, read 7 September 2026 - the formatting symptoms as described to accountants; given without a name or link

Integration dropping data between systems? Fix S — $300, 2 business days, fixed price.

Get my quote in 24h

Written by the Fixmation team.