Delivery service reconciliation — full walkthrough
The structure and reconciliation logic of the delivery service file, and the recurring unresolved POS sales variance.
This file reconciles POS/GL delivery-service sales and receivables to the deposit-in-transit expected per Loop, and generates the Intacct journal entries recording delivery-service revenue, fees, commissions, marketing costs, and sales-variance adjustments.
Source: Rackson_RRS_RCY_Review_Process.docx section 11. Prepared by: Maureen, with Jessie cross-trained as backup.
It is one of the more involved files in the close and is worth understanding in full, because it drives several P&L accounts — sales tax, marketing fees, commissions — as well as the balance sheet DIT.
File structure
Three sources:
- The sales journal export from R365 showing tenders by delivery service.
- The Loop payout/transaction report — a mass download of all transactions for the period.
- The journal entries exported from Loop.
The preparer enters the period-end date, the current GL balances by store, and the expected sales-entry tenders by store for each delivery service.
These inputs drive every downstream formula in the file — nothing else needs manual updating once the Inputs tab is correct.
Identically formatted: stores down the rows, sales/fees/adjustments across the columns. Each tab calculates:
- The expected DIT based on the Loop payout data — the net payout for any transaction dated on or after period end, or not yet paid out as of the data pull.
- The reconciling items — commissions, marketing fees, sales-tax adjustments, customer disputes/chargebacks — needed to bridge the current GL balance to that expected DIT.
Once the individual tabs are complete, this tab automatically generates the journal entry ready for import into Intacct.
Why this tab exists: Loop's native Intacct integration posts one entry per delivery service per store. At roughly 95 stores and 3 delivery services that is far too granular to review efficiently, so the import template consolidates everything into a manageable, reviewable entry.
Reconciliation logic
For the delivery-service receivable — i.e. after deposits and the sales entry have already posted.
Commissions, marketing fees, and any customer disputes/chargebacks per the Loop data.
As calculated from the Loop payout data.
Across the applicable stores as an adjusting entry.
Confirm the resulting GL balance for each delivery service ties to the calculated DIT. This is effectively a mini roll-forward of the receivable.
Special case — Cinnabon. A handful of Cinnabon-branded add-on locations are not captured in the standard Loop feed. Their DIT must be identified and added to the reconciliation manually rather than assumed to be included.
Column mapping reference
| Column | Source |
|---|---|
| POS | Pulled directly from the Intacct balance, which itself comes from the sales entry and payments. |
| Sales entry | Sourced from R365 (should match the POS/Q column), net of payments already made and net of marketplace-facilitator adjustments. |
| Delivery-service sales | Summed from the Loop data for that specific platform. |
| Marketplace facilitator tax adjustment | Calculated separately. This is the first place to look when the sales-tax-related columns don't tie. |
The recurring POS sales variance — known issue, not yet resolved
A persistent variance exists between sales recorded by the POS/R365 sales entry and sales reported by the delivery platform, with POS sales consistently reading lower than what the platform reports.
Working theory. Delivery platforms frequently mark up the menu price charged to the end customer relative to in-store POS pricing. The platform's reported "sales" figure reflects that marked-up price, while the POS captures only the in-store price. The markup difference functions as a covered cost that the platform effectively returns to the operator embedded within fees, rather than as a distinct, separately reported line.
This is a visibility issue, not an accuracy issue. Because the variance nets out through fees and reconciles at the total-company level, it does not create a P&L or balance sheet misstatement — it is an unexplained "black hole" in how the numbers are labelled rather than a cash or accuracy problem.
This has been raised with the client as worth investigating directly with the delivery platforms, and Rackson has been made aware, but it has not been resolved and the client has not yet spent the time to dig into it.
How to investigate a specific period's variance
Not the summary.
- The POS sales column
- The sales-entry column (R365 sales, less payments, less marketplace-facilitator adjustments)
- The platform's reported sales
It is the most common driver.
Illustrative example. A roughly $5,000 variance on DoorDash was flagged as material enough to look into individually rather than simply allocate and move on. After investigation it was treated similarly to the broader markup/covered-cost pattern described above.
Completion
Once all tabs are finalized, the preparer imports the resulting entries into Intacct as a single journal entry per delivery service — not per store — covering all stores.
Confirm the GL balance for each delivery service reconciles to the calculated DIT before marking the item complete on the checklist.
On the close checklist, Delivery Service Reconciliation and Delivery Service Fees are both WD4 tasks.
Related
- RRS delivery, maintenance and reporting workpapers — the RRS preparer steps and the import files
- RCY system and source data — the RCY Loop reconciliation including EZCater and the store 1354 Grubhub supplement
- Sales tax review — the marketplace-facilitator adjustment
- Troubleshooting — "the delivery service numbers don't match the platform's own reporting"