The Account Mapping page tells BuyerKiosk which QuickBooks Online account to use for each field on your daily DRS close report. Without complete mappings the system can't post journal entries, so this is the first thing to set up after connecting to QBO.
Each DRS field on the left, mapped to a QBO account on the right. Sections group related fields (Payments, Sales & Returns, COGS, etc.).
Who can use this: Admins only. The Manager, Shift Lead, Buyer, and Cashier roles don't have QuickBooks access.
Where to find it
From the sidebar: QuickBooks > Account Mapping. Direct URL: /admin/{typeNum}/quickbooks/mapping.
The page header shows your mapping progress (X / Y fields mapped) and a save button that activates when you have unsaved changes. The Dashboard's header shows the same count as a chip — when there are critical unmapped fields, it tints amber so you spot it at a glance.
How mapping works
Your nightly close report has ~40 financial fields (cashTendered, totalSales, taxCollected, newReturns, buyPaidCash, etc.). Each field needs to map to:
A QBO account — where the value goes (e.g.
Cash,Sales Income,Sales Tax Payable).An entry type —
debitorcredit. This is the base direction for a positive value.Optionally an offset account — when the field's accounting effect needs a balancing entry (e.g. cash + a corresponding revenue line).
When the nightly job runs, the system reads each field, looks up its mapping, and emits a journal line. The lines are summed to verify debits = credits.
Critical vs. optional fields
Fields are organized into categories that determine whether they block sync when unmapped:
Category | Examples | Sync-blocking? |
| cashTendered, visaActual, masterCardActual, gift card redemptions | ✅ Yes |
| newSales, usedSales, taxCollected, returns | ✅ Yes |
| newCost, usedCost, returnsCost | ✅ Yes |
| buyPaidCash, buyPaidCheck, buyPaidOffsite, buyPaidDigital | ✅ Yes |
| cashPaidIn, cashPaidOut, cashOverShort | ✅ Yes |
| giftCardsIssued, freightCollected, continuingFee | ✅ Yes |
Rows with unmapped critical fields show an amber ⚠️ warning icon next to the field name. Until every critical field is mapped (or marked "Not used at this store" — see below), the Approval Queue refuses to post.
"Not used at this store" — the opt-out
Some stores don't use every payment method. A store that doesn't take offsite buys never logs values to buyPaidOffsite. A store with no digital tender will never have a buyPaidDigital entry. These fields are technically in critical categories — but flagging them as "unmapped" forever would mean a permanent dashboard warning for fields you'll never use.
Every account dropdown's first option is "Not used at this store" — pick it to acknowledge the field as N/A.
The first option in every account dropdown lets you mark the field as N/A for your store.
When set:
The row dims to indicate it's intentionally unmapped.
The amber critical-field warning disappears.
The dashboard's "Critical fields unmapped" count excludes it.
The Approval Queue stops blocking on it.
If you later realize the store DOES take that payment type, just pick a real account from the same dropdown — the opt-out flag flips back off automatically.
Why this exists: the system defaults conservatively (every financial-category field is critical) because unmapped values otherwise silently fall to Cash Over/Short, which is much worse than a vocal warning. "Not used at this store" is the explicit acknowledgement that says "I know this field exists, my store doesn't use it, stop nagging."
Setting a mapping
For each row in the table:
Click the QBO account dropdown. The list is fetched live from your connected QBO company file and is searchable — start typing to filter.
Select the correct account.
Optionally set an offset account if the row needs one (see Offset accounts below).
Hit
Save changesin the header when you're done.
Mappings save in a batch, so you can edit several rows before committing.
Tip: Every mapping change is logged to the Audit Log as a mapping_updated event with the old and new account IDs. If a future variance turns out to be a mis-mapping, you can prove exactly when the mapping was changed and by whom.
AI Auto-map — let the system suggest mappings
Setting up mappings manually for a fresh store can take an hour. The Auto-map feature uses two layers of intelligence to suggest mappings for unmapped rows:
Heuristic engine — fuzzy-matches field names to your chart of accounts (e.g.
cashTendered→ "Cash" or "Cash on Hand") plus a cross-store learning model that watches what other stores have mapped fields to. Fast (milliseconds), no AI cost.LLM (gpt-5-mini) — fills gaps the heuristic isn't confident about by reasoning over the field description and account names. Takes a few seconds, capped at 5 runs per store per day.
Each section header has its own "Suggest with AI" button so you can scope suggestions to one group at a time.
Two ways to invoke:
Per-section — each section header (Payments, Sales & Returns, etc.) has a
Suggest with AIbutton that runs both engines scoped to just that section's fields.Page-level — the top toolbar's
Auto-mapbutton runs the heuristic across every unmapped field on the page (no LLM cost). ClickSuggest with AIin the suggestions banner to add the LLM pass.
Reviewing suggestions:
Suggestions appear as pre-filled dropdown values marked with a small ✨ sparkle indicator. They're not saved until you click Save changes. Review each one — the system is good but not perfect, and your chart of accounts is yours.
Tip: Auto-map is most useful on initial setup. Once your mappings are stable, you'll rarely need it again — and the cross-store learning model means future stores benefit from what your store mapped today.
Sign semantics (read this if you map Returns or Refunds)
DRS data uses negative numbers as a labeling convention for things like returns: newReturns: -3.99 means "a return of $3.99," not "negative $3.99 owed somewhere."
Each mapping row has a signSemantics column that controls how the system interprets the source value's sign:
Setting | Meaning | When to use |
| The sign of the source value carries meaning. Negative source values flip the entryType (DR ↔ CR). | Fields where positive vs negative is real (e.g. |
| The sign of the source value is just a labeling convention and the entryType is the truth. The amount is always abs(value). | Fields where negative is just how the DRS labels something (returns, refunds, void counts). |
The ABS badge next to a row's DR/CR badge indicates an absolute mapping; everything else is directional.
Field |
|
| Source | Posted as |
|
|
| ignored | DEBIT $3.99 to contra-revenue ✓ |
|
|
| ignored | DEBIT $3.99 to contra-revenue ✓ |
|
|
| (always positive) | CREDIT to Sales Revenue |
|
|
| matters: -$5 → DR (short = expense) | DEBIT $5 to Cash Over/Short |
Note for accountants: if a row's DR/CR badge looks "backwards" for what the field is, check whether it has an ABS badge. If yes, the entryType is the actual posting direction — the source value's sign is decoration only.
Offset accounts
Most DRS fields imply a paired entry. Cash paid for a buy debits the Cash asset account and credits the Inventory asset account; cash tendered for a sale debits Cash and credits Sales Revenue. The per-row Offset dropdown expresses this directly.
When you set an offset account on a field, the daily sync emits two journal lines per non-zero source value: the primary line at the field's main account, and a mirror-direction offset line at the offset account. So a $10.00 cashTendered field with primary Cash (DR) and offset Sales Revenue (CR) posts:
DR $10.00 Cash CR $10.00 Sales Revenue
That single field then balances internally — debits = credits for that pair — regardless of what's happening with other fields on the same close report.
When to leave the offset blank ("single-sided"):
Some fields don't have a natural double-entry partner inside the same close report. The dropdown's first option is -- No offset (single-sided) -- for these. Examples:
cashOverShort— the partner is the cash account, but cashOverShort itself stands alone in QBO as either an expense or expense reduction.Fields where another field on the same report is implicitly the partner (e.g.
cashTenderedandtotalSalesmay already balance each other out without explicit offsets).
If you're not sure whether to set an offset, check whether your daily JE balances when you leave it single-sided. If you see consistent variance, the field probably needs an offset. The Approval Queue's balance banner flags imbalances explicitly so you can iterate.
Tip: Setting offsets on every field that has a logical partner makes your daily JE balance to the penny on day one, instead of leaning on Cash Over/Short to absorb the gap. Time well spent during initial setup.
Mid-period changes
You can change a mapping at any time, but think about timing:
A mapping change applies to the next sync. Already-posted journal entries are not retroactively re-posted.
If you change a mapping mid-month and have already posted entries that used the old mapping, your books will have a mix. Either accept this and document the change date, or void the affected entries and re-post.
The Audit Log's mapping_updated event preserves the old → new account ids, so you can always reconstruct what was active when.
Reconnecting QBO and your mappings
If you disconnect and reconnect to a different QBO company file, your mapped account ids will no longer be valid (each QBO company has its own account id space). The system shows a banner if any mapped account no longer exists in the connected file. You'll need to re-map fields one by one — or use Auto-map / Suggest with AI to bulk-suggest replacements.
What's next
Connect & configure — required first step before mapping.
Daily approval workflow — what to do once mappings are complete.
Reconciliation — verifying mappings produce correct totals over time.



