You ran commissions on Desktop's rep field and Sales by Rep reports for years. After migration, QuickBooks Online hands you a dropdown of initials and no report. The data survives the crossing. The reporting doesn't. This is the precise anatomy of the breakage — and the recovery path.
QuickBooks Desktop treats sales reps as first-class objects. Three pieces, working together:
The Sales Rep list. Each rep is a named entry — initials on the form, linked to an employee, vendor, or other-name record underneath.
The REP field on sales forms. Every invoice and sales receipt carries rep attribution as a standard field.
Built-in Sales by Rep reports. Summary and Detail, pre-tax line amounts, any date range. This is the report most Desktop commission workflows are built on: run it, drop it next to the rate spreadsheet, pay the reps.
Worth being precise about what Desktop did not do: it never did the commission math. Reps, attribution, and revenue lived in Desktop; rates, tiers, and splits lived in a spreadsheet. The Sales by Rep report was the bridge between the two.
Run Intuit's Desktop-to-Online migration on a company file with rep tracking and this is the state you land in:
The REP field is demoted to a custom-field dropdown on sales forms — usually named "Sales Rep". Initials only. The link to the employee record: severed.
QBO has no Sales by Rep report. Not hidden behind a plan tier. Absent.
The Advanced rebuild produces wrong totals. "Rebuild it in QBO Advanced custom reports" is the standard advice — we did. The report builder sums tax-inclusive invoice headers; Desktop's reports were pre-tax line detail. If your invoices carry sales tax, the totals will not reconcile against Desktop.
Intuit's own AI assistant can't see transaction custom fields. Ask it where your rep data went and it will tell you the data isn't there. It is.
Intuit retires a Desktop version every year and stopped selling new US Desktop subscriptions in 2024. Desktop 2023 support ended 2026-05-31; Desktop 2024 follows on 2027-05-31. Every sunset pushes another wave of commissioned-rep businesses through the same migration — and every one of them lands in the state above, usually discovering it at the first month-end commission run after the switch.
Everything below can be done by hand. It is tedious by hand. The order matters.
If the Desktop machine or file still exists: open Reports → Sales → Sales by Rep Detail, set the date range to All, and export to CSV (the detail export — a fixed, predictable structure). Export the Sales Rep list too.
This file is the pre-migration truth: every transaction, with its rep, at pre-tax line amounts. It costs nothing today. Once the machine is decommissioned or the license lapses, it may be unrecoverable — and new US Desktop licenses stopped selling in 2024, so rebuilding the environment later is not a safe assumption.
In QuickBooks Online: Gear → Custom fields. The converter typically leaves a field named "Sales Rep" (or "Rep") attached to sales forms. Open a few recent migrated invoices and confirm the initials are present on the transactions themselves.
The field now holds bare initials with no link to any record. Build the mapping table once — initials → rep name → the person you actually pay — from the Desktop Sales Rep list you exported in step 1. Every downstream fix depends on this table.
Pick a closed period you know well. Compare the QBO transactions' custom-field values against the same period in the Desktop Detail export, line by line. By hand this means filtering transaction lists — QBO's reporting on custom fields is weak, which is the whole problem. Programmatically, the API returns the values when custom fields are requested on the read (QBO's enhanced custom fields).
Do not skip this. A commission statement built on unverified attribution is a dispute waiting for month-end.
Options: keep using the migrated custom field for new transactions; or adopt Class-per-rep, Intuit's commonly prescribed workaround (it works, at the cost of repurposing Classes). Whichever you choose, apply it forward only. Bulk-editing historical, closed-period transactions to re-tag reps pollutes the audit trail — leave history as it is and reconcile it through the mapping instead.
The report itself does not exist in QBO, so pick your poison: export transactions and pivot in a spreadsheet each period; use QBO Advanced custom reports with the tax-inclusive caveat from above and reconcile the difference; or use a tool that reads the custom field through the API and reports at pre-tax line level.
SalesRepFielder runs the flow above as its opening act. It exists because we did this by hand first.
On connect, it detects the migrated "Sales Rep" custom field and maps it — the migrant case is the designed-for case, not an edge case.
Upload your Desktop Sales by Rep Detail export (the CSV from step 1) and it rebuilds the rep roster and the initials mapping from it — the export's structure is fixed, so this is deterministic parsing, not guesswork.
Then it audits: replays your history against the QBO data and diffs, line by line, so you see exactly where attribution survived and where it didn't — before you trust a single statement. Replay receipt so far: 183/183 replayed statements matched, across 15 real files.
Going forward, it applies your commission rules and ends each run as rep statements plus a journal entry posted into your books. Opt-in write-back can restore a real "Sales Rep" custom field on new transactions — forward-tag only by default, for the closed-period reasons in step 5.
$10/payee/mo direct, $12/client file/mo for firms, no platform fee. 30-day trial, full product, no card.
Comparing tools for this? See SalesRepFielder vs Sales Cookie — receipts included.
Not natively. QBO has no built-in rep field on transactions. Migrants get Desktop's REP field carried over as a custom field on sales forms — a dropdown of initials, unlinked from any employee or vendor record. QBO-native companies have to improvise one: a custom field, a Class per rep, a Location, or a customer→rep mapping.
No. It is not tier-gated — it does not exist. The closest substitutes are filtering sales reports by your rep custom field where supported, or a QBO Advanced custom report, which sums tax-inclusive headers and will not reconcile against Desktop.
No. The attribution survives on each migrated transaction in a custom field, usually named "Sales Rep" — initials only. What is lost is the reporting and the employee-record link. The values are visible on transactions and retrievable through the QBO API when custom fields are requested on the read.
The Advanced custom-report path sums transaction headers, which are tax-inclusive. Desktop's Sales by Rep reports were pre-tax line detail. Any sales tax on your invoices puts the two out of agreement — the discrepancy is structural, not a data error.
No — it cannot see transaction custom fields, so it will report that the data isn't there. The data is there; the assistant's view of it isn't.
The Sales by Rep Detail report, all dates, to CSV — plus the Sales Rep list. That detail export is the file every recovery and verification step runs on. Support sunsets do not delete your install, but decommissioned machines do; export now.