QuickBooks Package (QBD)

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.

You need the Admin role to manage QuickBooks mapping or generate, download, mark posted, or void a package. Payroll and Approver teammates can read the package page and its version history, but see Only admins can generate, download and post QuickBooks packages. in place of its controls. This also applies to downloading a package someone generated earlier.

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 (see Payroll History)

Under its title, the QuickBooks package page reads "The payroll journal, payment records, and reconciliation workbook for QuickBooks Desktop, with every version kept".

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.

If your company has no union contracts, unused union dues, union benefit, and uncoded employer fringe mappings are hidden. Any of those categories already used in your payroll history stays available to map and confirm.

Categories are grouped into sections in the order they read on the export:

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 (the main button in the Account mapping header while the list is empty) to pull in every category your production's runs have actually used, with a suggested QuickBooks account name for each. Until you do, the table reads No account mappings yet: "Seed from payroll history lists the payroll amounts this production posts, each with a suggested QuickBooks account. Clearing, withholding and employer payroll tax arrive confirmed. Compare the rest with your QuickBooks chart of accounts and confirm each one." 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.

Each row is named in words, such as Employee withholding — New York City, Representative fees payable or Expense — uncoded employer fringe lines, and the package's blockers name it the same way. If your payroll lines spell one union fund two ways, for example AEA dues and AEA Dues, both rows read Union dues withheld — AEA Dues. Each of them then adds how its payroll lines spell the fund, such as Fund name on payroll lines: “AEA dues”, and a blocker for one of them gives the same spelling. Only Greenroom staff see the internal key behind a row's name.

A banner at the top always states plainly how many of the required categories are confirmed ("N of M required payroll amounts confirmed") — this is the same gate that generation itself checks, so nothing you see there can disagree with what actually happens when you generate. Until every one is confirmed, it adds "Package generation unlocks once every required payroll amount is confirmed. Compare each suggested account with this production's QuickBooks chart of accounts before you confirm it." What's still blocking is listed by reason, one line each with its count and what to do: No mapping row ("Seed from payroll history to create them.") or Needs confirmation ("Confirm each in the table below."). Open a line to see the payroll amounts behind it, grouped by section; a line of five or fewer starts open.

Uploading your chart of accounts

Instead of retyping account names by hand, click Upload CoA (.csv / .xlsx) and provide a .csv or .xlsx export from QuickBooks Desktop (an "account" or "name" column, plus an optional "type" column). The button sits in the Account mapping header once the list has been seeded, with Seed from payroll history beside it. 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. An export that repeats a name many times can be more than Greenroom can apply at once, because each checked row is applied to every mapping row it matches. Apply [N] matches then stops with "Those matches are too large to apply at once — uncheck some rows, apply, then apply the rest." Applying closes the preview, so for the rest, upload the file again and uncheck the rows you've already applied.

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, one bullet per problem — a specific unmapped or unconfirmed category, a negative line amount, a check-numbered payee missing a check number, a direct deposit with no payment number or one that was voided (see Direct-deposit payment numbers), a child trust remittance that doesn't match its allocation or has no 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.

A payroll that is still being submitted can't produce a package yet, because its direct deposits get their payment numbers as the submit finishes. While the run reads Approved or Processing, the banner says "This payroll hasn't finished submitting, so its payments don't have their payment numbers yet. You can generate the QuickBooks package once the payroll shows Paying out or Paid."

The package doesn't know how a check went out. A check we mailed is posted exactly like one you printed: a numbered paper check, expected to clear your bank under that number. The package doesn't read the physical-check register either, so a mailed check that was canceled or came back still appears in it as issued; account for those in your books yourself.

If the run can't produce a package at all — our tax partner 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.

Payroll amounts without a confirmed account

A payroll amount with no QuickBooks account, or one whose account isn't confirmed yet, gets its own line, named as Settings → QuickBooks names it, with what to do there:

• "No QuickBooks account is mapped for “Expense — GL 4310”. In Settings → QuickBooks, click Seed from payroll history to add it. If it isn't confirmed yet, check its account and click Confirm."
• "The QuickBooks account for “Representative fees payable” isn't confirmed yet. In Settings → QuickBooks, check it against your QuickBooks chart of accounts and click Confirm."

When two payroll amounts share a name because your payroll lines spell one fund two ways (see Seeding and confirming), the line adds how the payroll lines spell the fund, so you can tell which one it means: "No QuickBooks account is mapped for “Union dues withheld — AEA Dues” (fund name on payroll lines: “AEA dues”). …"

Only an Admin can open Settings → QuickBooks, so a Payroll or Approver teammate sees all of these as one line, where the first of them would be: "3 payroll amounts need a confirmed QuickBooks account. Ask an Admin teammate to confirm them in Settings → QuickBooks." With a single amount it reads "1 payroll amount needs a confirmed QuickBooks account. Ask an Admin teammate to confirm it in Settings → QuickBooks." Every other blocker reads the same whatever your role.

Fund checks that don't match

A union fund check numbered at submit has to match what this payroll owes that fund. When it doesn't, the blocker names the fund the way its settlement rows do, says what the check is for and what the payroll owes, and ends Contact Greenroom. For example: "[Fund]: fund check #5059 is for $1,250.00, but this payroll owes the fund $1,180.00 by check. Contact Greenroom." Several checks for one fund read "fund checks #5059, #5060 total $2,360.00". For a fund that takes no check from this payroll, the blocker says why instead:

• "…, but the production pays this fund directly, so this payroll owes it no check. Contact Greenroom."
• "…, but this fund is reported on the union's .045 box-office settlement, so this payroll owes it no check. Contact Greenroom."
• "…, but this payroll owes the fund nothing. Contact Greenroom."

Warnings

Once blockers clear, generation can still carry warnings. They don't stop it, but each says what to check before you paste anything into your books. They're listed under the package's header, which for an Admin reads, for example, Ready to generate · 1 standing warning. The README tab repeats each one after Validation warning:, and the PDF lists them too.

• Taxes and direct deposits follow a default split. Any payroll with taxes carries this one: "The tax and direct-deposit settlement rows follow a default split, which may not match how these payments appear on your bank statement. Compare them with your bank feed before you paste the settlement blocks."
• A tax Greenroom doesn't recognize: "Greenroom doesn't recognize the tax jurisdiction of [tax]. Before you paste the settlement blocks, check which tax authority the rows marked “Other tax authority” are paid to." Those settlement rows name the authority Other tax authority in the Memo, which you paste into QuickBooks, and mark it Other tax authority — verify before paste only where nothing is pasted: in the Expected Bank Match and on the Tax Liabilities tab.
• Representative payments. Greenroom doesn't pay representatives: the production pays each one itself and records the payment in QuickBooks. "Greenroom doesn't pay representatives, so pay each one yourself and record the payment in QuickBooks. Each representative's payment is listed under “Manual settlement required”, outside the settlement blocks you paste." See Representative payments.

What's in the package

Generating produces two files together — a full Excel workbook and a condensed PDF — covering the same package:

For a run with no union activity in a company with no union contracts, the package omits the Union Remittances tab and zero summary rows for union benefits, union checks, .045 settlement, and funds paid directly. Reconciliation omits the empty Union Benefit Payable section and labels the remaining deduction section Deduction Liabilities. Any nonzero union amount keeps the relevant union sections visible. Wages, taxes, ordinary deductions, representative payables, and child trust allocations remain in the package.

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/26/2026-01: the week-ending Sunday, then a two-digit count for that week), not a random ID, so regenerating a package for the same run reuses the same entry number rather than minting a new one.

Representative payments

A representative's commission is withheld from the payee's pay, but Greenroom doesn't pass it to the representative: the production pays each representative itself, outside payroll, and records that payment in QuickBooks. The package keeps those payments out of the rows you paste:

• Cash Settlement Batch: below the settlement blocks, under Manual settlement required — DO NOT PASTE, each representative has one row, referenced REP-1, REP-2 and so on. Its memo reads "[Representative] — Manual settlement required — do not paste (paid outside payroll)", and its Expected Bank Match reads No bank movement — settle manually. The PDF lists the same rows under Manual settlement required — do not paste.
• Payroll Summary: Representative fees withheld carries the note Paid by the production outside payroll, and Representative payable — manual settlement gives the amount owed to representatives.
• Reconciliation: that amount is expected to stay on the books after you paste, with the reason Representative payable — paid by the production outside payroll (manual).

Direct-deposit payment numbers

Every direct deposit on a payroll gets a payment number as the payroll's submit finishes: "E" and six digits, counting up from E000001 for each production (see Payment numbers). The package carries them:

• Cash Settlement Batch: each direct deposit is its own row, with its payment number in Check No./Ref and the payee's name as the memo. Together the rows still clear the bank as one ACH debit, so each row's Expected Bank Match reads Part of one ACH debit: payroll direct deposit sweep. The clearing account and the total don't change.
• Direct Deposit Detail: a Payment Number column gives each payee's number.
• PDF: the Cash Settlement page adds a line under the bank's heading saying the rows clear as one debit, for example "The 7 direct-deposit rows, E000001 to E000007, clear the bank as one ACH debit of $7,894.77." With a single direct deposit it reads "The direct-deposit row E000001 clears the bank as one ACH debit of $900.00."
• README: the duplicate-number warning names only the tax references: "Tax references (TAX-*) repeat from payroll to payroll and will trigger QuickBooks Desktop's duplicate-number warning — this is expected. Direct-deposit payment numbers (E000001, E000002, …) are unique within this production."

A payroll that was never numbered, such as one submitted before Greenroom began numbering direct deposits, exports as it always has. All of its direct deposits settle as one ACH-DD row, Direct Deposit Detail has a Payment Reference column reading ACH-DD, the PDF has no extra line, and the README says "Duplicate check references (ACH-DD, TAX-*) will trigger QuickBooks Desktop's duplicate-number warning — this is expected."

Two blockers are about payment numbers:

• A direct deposit with no number on a payroll that has them: "[Name]: this direct-deposit payment has no payment number. Contact Greenroom before generating the QuickBooks package."
• A voided payment: "[Name]: direct-deposit payment [number] was voided and cannot be posted to QuickBooks as a settled payment." A recorded void is permanent, so from then on this payroll can't produce a package, a Revision included.

No screen in Greenroom voids a direct deposit. When a payment has to be recorded as voided, Greenroom records it by hand, after confirming with our tax partner that the payment itself, not just the payroll, was voided. Outside this package a voided payment's number is shown unchanged, the same way a voided paper check's number is: on the run's payment rows, in the payee's Payment history, in the payroll register and its CSV, and on the payee's own statement.

A package generated before the void doesn't change. It still shows that payment as settled, and it can still be downloaded and marked Posted. If it's already in QuickBooks, the voided payment needs a correcting entry there. A voided payment number is never given to another payment.

Package lifecycle

Each generated package moves through a status, shown next to its version number in the package history:

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.

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.