QuickBooks Package (QBD)
Generating a versioned QuickBooks Desktop accounting package from a payroll run, and mapping your categories to real QuickBooks accounts
Replaces the QuickBooks CSV export
Greenroom used to have a single-sheet "QuickBooks CSV" report. It's been retired (TCG-1588) and replaced entirely by the QuickBooks Package described on this page — a versioned, multi-tab workbook with an audit trail, not a plain CSV. If older material still mentions a "QuickBooks CSV" report, it's describing the retired feature.
The QuickBooks Package (internally "QBD," for QuickBooks Desktop) turns one finalized payroll run into a complete accounting package: a recognition journal entry, a paste-ready cash settlement batch, supporting detail tabs, and a reconciliation that ties the two together. It's built for QuickBooks Desktop — you download the file and enter or paste it into your books yourself, rather than a live sync to QuickBooks Online.
Where to find it
Two places, for two different jobs — plus a shortcut:
- Settings → QuickBooks — set up and confirm the account mapping (do this first)
- Reports → QuickBooks package (QBD) — generate, download, and track packages per run
- A finished run's detail page — the QuickBooks package button in its header opens that same Reports page with the run already selected (this button was a dead "QuickBooks CSV" link until 2026-08-23 — see Payroll History)
Only available once your payroll provider is live
The QuickBooks package builds from finalized payroll runs, so it has nothing to build from until Check (Greenroom's payroll provider) is active on your environment. Until then, both entry points show "Available as we finalize payroll" instead of a working generator. This isn't a per-company or demo-only gate — it's a one-time environment switch that flips on for everyone once payroll processing is live.
Setting up account mapping
Every line on a payroll run resolves to a QuickBooks account through a category — things like "Employee withholding — Federal," "Employer payroll tax — payable," or a specific union fund's dues and benefits. Settings → QuickBooks lists every category your production has ever used and lets you map each one to a real account name from your QuickBooks file.
On screen that column is headed Payroll amount rather than "Category", because that's what the rows are — the payroll figures that need an account, not accounting categories you define. A row Greenroom recognises but that none of your production's runs has actually produced carries a Not observed badge — it isn't required, and it doesn't block generation. (A different badge, "Not used by any mapping yet", appears in the chart-of-accounts upload preview, on an uploaded account name that matches no row.)
Withholding rows are listed by jurisdiction — Federal, NY, NYC — worked out from the tax lines your runs have actually carried. Until 2026-08-29 the list lost that detail: it counted a single "other" withholding row as required while badging the Federal and NY rows that every journal entry posts to as Not observed. If your mapping list still looks like that, click Seed from payroll history again and it will sort itself out.
Categories are grouped into sections in the order they read on the export:
| Section | Example categories |
|---|---|
| Clearing | Payroll settlement clearing (net pay + settlement) |
| Employee withholding | Federal, NY, NYC, and other jurisdictions |
| Employer payroll tax | Expense and payable sides |
| Union dues withheld | Per union / per fund |
| Union benefits payable | Per union / per fund |
| Deductions | Pre-tax and other |
| Representatives | Representative fees payable |
| Expenses | Per GL code, or "uncoded" by line kind if a line has no GL code |
| Rounding | A category exists for a residual of 3¢ or less, but no screen or import can create a mapping for it today — a journal entry that doesn't balance is treated as drift and blocks generation instead (see below) |
A handful of structural categories (clearing, the four withholding jurisdictions, employer tax) ship pre-confirmed with sensible defaults so a brand-new production isn't blocked immediately. Everything else — union funds, GL-coded expenses, deductions, representative fees — arrives unconfirmed the first time it's seen. An auto-suggested account name is a starting point, not a pass: you have to explicitly click Confirm on each row before it counts.
Seeding and confirming
Click Seed from payroll history to pull in every category your production's runs have actually used, with a suggested QuickBooks account name for each. Then work through the list:
- Edit a row to change its QuickBooks account name, account type (Expense, Other Current Liability, Bank, Income, or Other), or — for the clearing category only — a legacy alias.
- Confirm a row once its account name matches your real QuickBooks chart of accounts.
A banner at the top always states plainly how many of the required categories are confirmed, and lists exactly which ones are blocking (either "no mapping row" or "needs confirmation") — this is the same gate that generation itself checks, so nothing you see there can disagree with what actually happens when you generate.
Uploading your chart of accounts
Instead of retyping account names by hand, click Upload CoA and provide a .csv or .xlsx export from QuickBooks Desktop (an "account" or "name" column, plus an optional "type" column). Greenroom matches each uploaded account name against your current mapping rows — case-insensitively, ignoring extra whitespace — and shows you a preview of what would change before anything is applied. Uploaded names with no match are listed separately for manual mapping; matched rows apply as confirmed.
Generating a package
From Reports → QuickBooks package (QBD), pick a run and open it. If every required category is mapped and confirmed, Generate package is enabled; otherwise you'll see a blocked banner listing exactly what's stopping it — a specific unmapped or unconfirmed category, a negative line amount, a check-numbered payee missing a check number, a numbers mismatch between a union's routed pay and the fund check written for it, or a journal entry whose debits and credits don't balance. Nothing generates partially — either every check passes or nothing is produced.
If the run can't produce a package at all — Check voided it, or its figures couldn't be assembled — the page says why in a card under the run picker, rather than showing nothing below it.
An imbalance is drift, not rounding
A journal entry that doesn't balance blocks generation even when the difference is within 3¢, and there's no Rounding account to map your way past it — the blocker reads "…within the ±3¢ tolerance, but nothing absorbs it — an imbalance is drift, not rounding. Investigate the per-entry drift; do not post." Earlier wording told you to map and confirm a Rounding account, which no screen can create; investigating which entry drifted is the only path.
Amendment runs aren't supported yet
Generating a package for an amendment run is blocked outright today — amendments settle through the provider's own correction flow, and a Phase-1 export would post the delta incorrectly. This is a known, deliberate limitation, not a bug.
Once blockers clear, generation can still carry warnings that don't stop it but are worth reading before you paste anything into your books — for example, an unrecognized tax jurisdiction, a tax/direct-deposit split that used a default assumption rather than your real bank feed, or representative payments that have no payment rail yet and need to be settled manually outside this package.
What's in the package
Generating produces two files together — a full Excel workbook and a condensed PDF — covering the same package:
| Tab | Contents |
|---|---|
| README | Package summary and, on a Revision, instructions for reversing the prior posted entry |
| Payroll Summary | Run-level totals |
| Recognition JE | The double-entry recognition journal entry — debits and credits by account |
| Cash Settlement Batch | Paste-ready rows clearing what's actually moved in cash |
| Direct Deposit Detail | Per-payee direct-deposit lines |
| Paper Check Register | Per-payee paper-check lines, with check numbers |
| Tax Liabilities | Withholding and employer tax, by jurisdiction |
| Union Remittances | Dues and benefits, by union and fund |
| Reconciliation | Ties the journal entry's liability credits to the settlement batch's debits, bucket by bucket |
| Account Mapping | The exact category → account mapping this package used, for the record |
| Legacy Check Format (optional) | Only rendered when your production has that profile setting on |
The Entry No. on every package is deterministic — it's built from the run's type and its operating week or pay date (for example, GR Payroll WE 07/28/2026), not a random ID, so regenerating a package for the same run reuses the same entry number rather than minting a new one.
Package lifecycle
Each generated package moves through a status, shown next to its version number in the package history:
| Status | Meaning |
|---|---|
| Draft | Just started generating — no file exists yet |
| Ready for review | The workbook and PDF exist and can be downloaded |
| Downloaded | Someone has pulled the file at least once |
| Posted | You've attested the package was entered into QuickBooks and reconciled |
| Superseded | A newer version replaced this one |
| Voided | Withdrawn — permanent |
Every generation adds a new row rather than overwriting the last one — the history above shows a first version that was superseded by a second, now Posted, version of the same run's package.
Mark Posted only becomes available after the file has actually been downloaded — the attestation text is literally "posted to QuickBooks and reconciled," so it can't be applied to a file nobody has pulled yet. Confirming it is a real statement of fact, not a formality.
Regenerating rebuilds the package from current data and the current account mapping, and shows you exactly what changed in that mapping since the last generation before you confirm. Regenerating over a package that's already been marked Posted is different: it's restricted to super admins, requires an explicit override confirmation, and produces a clearly labeled Revision rather than silently overwriting — because a bookkeeper needs to know to reverse or re-edit the already-posted journal entry (same Entry No.) before entering the new one.
A run voided at the payroll provider can't produce a package at all
That's a different thing from voiding a package. If Check voids the run, its tax calculation and cash requirement are reversed, so generating a QuickBooks package for it is refused outright — the run stays visible and marked rather than disappearing from the picker, and this page states the refusal in a card under the picker. See Reports Overview.
Voiding a package is permanent — a voided package can never come back, though the file itself stays downloadable for the record. Voiding a package that's already Posted requires the same super-admin override as regenerating past one, since it asserts your books no longer reflect that export.
Next steps
Set up Chart of Accounts (GL Codes) first if you haven't — the QuickBooks package's expense categories are driven by the same GL coding on your payees' pay rates and adjustment lines. See Company Reports for the date-range rollup across paid runs, or return to the Reports Overview.