QuickBooks Changed Its Export Format on August 31 — Here's What Changed, and What to Check Now

Intuit's QuickBooks Online report format migration is live. The change was originally set for June 30, 2026, then pushed to August 31 — Intuit quietly updated its developer blog on June 26 to confirm the later date — and August 31 has now come and gone. If your Fintech upload, Excel macros, or any QBO-connected workflow hasn't broken yet, that means either you already fixed it or you haven't pulled a fresh export since the cutover. Worth confirming now, before you need that report and find out the hard way.

We didn't wait to find out the hard way ourselves. We found out five months early, when our Fintech upload broke in March with no warning from Intuit — a live account of ours started getting the new format before the general rollout. That early break gave us time to reverse-engineer every change well before most distributors hit the real cutover. This article is the playbook we used, updated now that the migration is fully live.

What Changed on August 31

On March 30, 2026, Intuit published "Upcoming Changes to Reports APIs" on their developer blog. As of August 31, 2026, the old format is gone for good across all 29 supported report types. Here's what changed:

Column headers renamed — "ALL CAPS" to "Title Case." Any parser, macro, or VLOOKUP that matches on an exact header string will fail. "DATE" is gone. "AMOUNT" is gone. If your Excel formula references a column called "TOTAL," it's now looking for a column that doesn't exist.

Row ordering is no longer stable. Row indices are generated dynamically now. If your workflow assumes "row 3 is always the first account line" — that assumption is broken.

Null values changed. Fields that previously returned `0` now return an empty string `""`. Any SUM formula, any numeric parser, any system expecting a zero gets a blank instead.

Account nesting behavior changed. Child accounts now always nest under their parent, even when the parent has transactions. This restructures the output of every Balance Sheet, P&L, and Trial Balance export.

Split account fields changed. Used to show "-Split-" when no split account existed. Now returns blank.

Date summarization capped. Yearly reports summarized by day used to return 365 columns. Now capped at 100, with everything beyond that bucketed into "Others."

Undocumented report endpoints removed. Only the 29 officially supported report types survive. If you built anything on an unlisted endpoint, it's gone.

The 29 surviving report types include: Profit and Loss, Balance Sheet, Cash Flow, A/R Aging Detail, A/P Aging Detail, General Ledger, Trial Balance, Inventory Valuation, Sales by Customer, Sales by Product, Vendor Balance, Journal Report, and more. See the full list at the Intuit Developer Blog.

If You Upload to Fintech, This Is Your Most Urgent Problem

Fintech processes $53 billion in annual alcohol purchases across over 1 million distributor-to-client B2B relationships through its PaymentSource platform. PaymentSource expects invoice data in a very specific tab-delimited format — exact column names, CRLF line endings (not LF), and a specific sign convention on quantities.

When we first hit this break in March, it came down to three simultaneous changes in the Journal export:

1. The header column "Date" was renamed to "Transaction date" — our parser searched for an exact match and never found it.
2. Detail rows now repeat metadata on every line — date, type, invoice number, customer name now appear on every row instead of only the first. Our row classifier treated every line as a new invoice header.
3. Quantity signs were flipped — sale quantities that exported as negative (inventory-out, as QBO had always done it) now come through as positive. Fintech ingested every quantity with the wrong sign.

Any one of those changes breaks a Fintech upload. All three arrived simultaneously, with no advance notice — and they've now arrived for every QBO-to-Fintech workflow whether it was ready or not. The old format's safety net is gone as of August 31.

If you export from QBO to Fintech — whether through an Excel macro, middleware, or an in-house tool — don't wait to find out the hard way. Pull a fresh Journal export today, run it through your existing workflow, and confirm Fintech still accepts it. If it returns "0 records found," you're looking at one of the three breaks above — and unlike our March break, you're finding out with a documented playbook in hand instead of a silent failure.

What to Fix Now

1. Check your headers first. Pull your most critical QBO reports (Journal, P&L, A/R Aging, A/P Aging) and compare the column headers to a version you saved before this whole thing started. "Date" → "Transaction date" is the most common break. Fix every exact-match header reference in your macros or parsers now — there's no old-format fallback left if you put it off.

2. Stop depending on row positions. If your workflow identifies fields by column letter or row number, rewrite it to identify by column header. Column A won't always be what you expect.

3. Add null handling where you had zeros. Every numeric field that could return blank instead of zero needs a null check. `IF(ISBLANK(A1),0,A1)` in Excel. Explicit None/NaN handling in any code.

4. Verify quantity signs on your Fintech output. If your upload is being rejected and the data looks structurally correct, check whether debit/credit signs are inverted. The Journal export flip from negative to positive quantities is subtle and will pass a structure check while still causing Fintech to reject the file.

5. Talk to every vendor that reads your QBO exports. If you upload to Fintech, a payroll processor, a tax prep tool, or any SaaS integration — ask them directly whether their import parser has been updated for the new format. Some will have already fixed it quietly. Others won't know until you ask.

6. If you have an API integration, note that the `testing_migration` query parameter Intuit offered to preview the new format during the transition window no longer gives you a side-by-side safety net — both formats aren't live at once anymore. Test your parsing logic directly against live report calls now; there's no old-format fallback left to compare against if something's off.

What We Built to Handle This

After we hit the March break, we rewrote our Fintech upload builder to handle both the old and new QBO export formats automatically. The parser now detects which format it's reading based on the header row, adjusts its row classification logic, corrects the quantity sign convention, and rebuilds the output file to Fintech's exact spec — CRLF line endings, the two-blank-row separator structure, all of it.

We've built format-drift detection into ThirstMetrics, our operations platform for beverage distributors. When a QBO export comes in, the system fingerprints the file structure, compares it to what it expects, and flags changes before they can silently corrupt your data downstream.

If you're a beverage distributor still exposed to this — whether you hit an early break like we did, or you just haven't tested against the new format yet — reach out. The deadline has passed, which means the fix is no longer optional.

Source: [Upcoming changes to Reports APIs — Intuit Developer Blog, March 30, 2026, updated 6/26/26 with the deadline extension to August 31, 2026](https://medium.com/intuitdev/upcoming-changes-to-reports-apis-5083ec9aadce)

Additional reference: [QuickBooks Online Reports API: Best practices and troubleshooting — Intuit Developer Blog, February 2026](https://medium.com/intuitdev/quickbooks-online-reports-api-best-practices-and-troubleshooting-31edc9934b4c)

[Fintech Celebrates 1 Million Distributor-to-Client Connections — BusinessWire, January 2024](https://www.businesswire.com/news/home/20240123129581/en/Fintech-Celebrates-Remarkable-Milestone-1-Million-Alcohol-Distributor-to-Client-Connections-with-PaymentSource)