Post the Day, Not the Deposit: Why Your Bank Feed Isn't Your Sales Number

Categorizing the deposit is hard to resist because it appears to work. The queue clears, the deposit gets categorized, and at the end of the month the bank account reconciles perfectly. That's the trap, and it's a common one: your bank account balances but your profit and loss statement is still wrong. On the ordinary Saturday below, the revenue line is overstated by about 14%, and by a different amount the rest of the week, which is why there's no single adjusting entry that fixes it. Recording the day properly takes several steps. None of them has to be manual.
If your bookkeeper already builds a summary entry from POS reports, the question is how often. Daily and you've solved most of this — what's left is how much of the day made it in, since a summary built by hand under time pressure tends to lose the same detail every time: one sales line rather than four, tips folded in with service charges, tenders lumped together. Weekly or monthly and that problem stacks up with two others: the numbers arrive too late to act on, and the deposits have been arriving all along with no entry to reconcile against.
Can you record sales from your bank feed?
You can categorize a deposit as income, but the deposit is not the sale. A bank feed tells you what settled and on what day — not what you sold, when you sold it, or what the money was made up of. Several things sit between what you sold and what lands in the bank: fees, sales tax, tips, cash, gift cards, and the date itself.
The deposit might already be net of fees. Many processors take their cut before the money lands. Where yours does, booking the deposit as revenue understates sales by the amount of that fee, though the tax and tips inside the deposit usually push the deposit the other way, as the example below shows. Either way the fee itself disappears: you paid it, but nothing in your books says so. It's one of the few costs you can actually renegotiate, and you can't negotiate a rate you can't see.
Sales tax and tips aren't revenue. Both ride inside that deposit, and both are money you're holding for someone else. Book the gross amount as income and your top line absorbs both. The tax is owed to the taxing authority, but it's sitting in your revenue instead of a liability account. The tips are owed to your staff, and paying them out looks like an expense instead of settling a debt you were already carrying.
Cash and gift cards don't behave like credit cards at all. Cash rung at the register appears in your sales report but in no deposit until someone makes a bank run, so cash revenue is missing from your books for days, and a drawer that came up short never shows at all. Gift cards move in two directions: selling one brings in money you haven't earned, while redeeming one earns revenue and no money moves at all. The feed sees the gift card sale and is blind to the redemption.
And the date on the deposit isn't the date of the sale. A weekend's card batches often settle together on Monday or Tuesday, and third-party delivery pays on its own cadence, net of commission. So the end of your month settles in the next one, and revenue lands in the wrong period at every month end.
Every one of those gaps shows up on an ordinary Saturday. Here's one location, one day, and the deposit that eventually turned up for that day.
| Line | Amount |
|---|---|
| What you earned | |
| Food sales | $12,480.00 |
| Beverage sales | $4,215.00 |
| Merchandise | $640.00 |
| Discounts & comps | ($350.00) |
| Net sales | $16,985.00 |
| Also collected — not revenue | |
| Sales tax collected, 7% | $1,188.95 |
| Tips, 20% | $3,397.00 |
| Gift cards sold | $300.00 |
| Total collected | $21,870.95 |
| How guests paid | |
| Cash | $1,865.00 |
| Credit cards | $19,830.95 |
| Gift cards redeemed | $175.00 |
| Total tendered | $21,870.95 |
| What the bank saw, on Tuesday | |
| Card batch | $19,830.95 |
| Processing fees, 2.6% | ($515.60) |
| Net deposit | $19,315.35 |
The day was $16,985.00 of net sales. The deposit was $19,315.35 — about 14% higher. Categorize it as Sales and you've overstated revenue by that much while recording none of the tax you owe, none of the tips you're holding for staff, none of the gift card liability, and none of the fee you paid. The cash doesn't appear at all. And everything you did record is dated three days late.
And the gap moves. Next Saturday the mix shifts and it's a different number and a different percentage. No fudge factor fixes the gap, because it isn't one error — it's several, moving independently. That's what makes it compound: your food and labor percentages are measured against a top line that's wrong by a different amount each day, so it isn't only the numbers that are off — the trend is off too. Every decision you make from those percentages carries the error with it.
What is a daily sales posting?
A daily sales posting records one business day of sales on that day's date: revenue by category, sales tax as a liability, tips as a payable, discounts and comps as themselves, any processing fee you can see, posted as an expense, and each tender routed to the account that holds it until the money actually arrives. It balances on its own: sales and adjustments tie to the tenders that paid for them. Nothing waits on the bank.
The form varies. Depending on your platform and setup, the day can post as a journal entry, a sales receipt, or an invoice, and what makes any of them a good posting is the same: dated to the business day, split the way you read your business, and balanced.
The important word is business day. A bar closing at 2 a.m. rings a round at 1:40 a.m. that belongs to Saturday, not Sunday, and your POS knows that because it runs on a business date with its own start hour. Post on business dates and your books line up with the shift reports your managers already work from. Post on anything else and they don't — every weekend, and every month boundary.
Here's that same Saturday posted properly: the day recorded on its own date, in balance, without waiting on the bank for anything. The example assumes your processor nets its fee from the deposit and reports that fee to you. If yours bills monthly instead, the deposit comes in gross and the fee posts on its own when it's billed.
| Account | Debit | Credit |
|---|---|---|
| Revenue | ||
| Food sales | $12,480.00 | |
| Beverage sales | $4,215.00 | |
| Merchandise | $640.00 | |
| Discounts & comps | $350.00 | |
| Money you're holding | ||
| Sales tax payable | $1,188.95 | |
| Tips payable | $3,397.00 | |
| Gift card liability — sold | $300.00 | |
| Gift card liability — redeemed | $175.00 | |
| What it cost you | ||
| Processing fees | $515.60 | |
| Where the money is | ||
| Cash on hand | $1,865.00 | |
| Due from merchant services | $19,315.35 | |
| Totals — in balance | $22,220.95 | $22,220.95 |
Why not just catch up at month-end?
Catching up at month-end doesn't reduce the work. It moves the same thirty days into the week you have the least room in, and lets errors get expensive along the way. A $60 tender mismatch caught Tuesday morning is a two-minute question for the manager who still remembers the shift. If it surfaces five weeks later, nobody can reconstruct it, and the cheapest answer is to write it off. A gap between what the register rang and what the bank received is where money goes missing most easily — and the evidence is gone within a week.
Waiting also makes your interim numbers useless. Vendor bills and payroll post as they arrive, so a mid-month profit and loss statement shows two weeks of food, labor, and rent against a revenue line that's still empty. Nobody reads a statement like that, and by the time the real numbers exist the month is over. Daily postings also give you the comparison every operator asks for first: this Saturday against last Saturday, which exists only if each Saturday is its own entry.
What does automated daily sales posting look like?
The only thing that actually stops people is time. Building a daily posting by hand runs fifteen or twenty minutes per location per day, forever, which is exactly why the deposit-as-revenue shortcut exists. Almost nobody abandons daily sales accounting because they decided it was wrong. They abandon it because they've missed eleven days and catching up now feels like a project. Being behind isn't a reason not to start. You don't have to catch up first.
Automated daily sales posting means each business day is already in your books before anyone opens them, built from the POS's record of the day and dated to that day. It's usually more detailed than the hand-built version, too — there's no clock to work against, so nothing gets collapsed to save fifteen minutes. And it happens on the days nobody has time for it, including Christmas Eve.
On a normal morning there's almost nothing to do. Yesterday's sales are already posted for every location, the expected deposits are already recorded, and the only thing left is confirming the real ones arrived. Each location posts on its own, so ten sites take no longer than one, and every major accounting system gives you a way to break the sales out for comparison: classes and locations in QuickBooks, tracking categories in Xero, segments in Oracle NetSuite, dimensions in Sage Intacct.
How Shogo does it
Shogo pulls the prior business day from your POS once the day is final, waiting for the POS's own end-of-day cutoff so nothing posts before the day is complete. It then posts that day to your accounting system, dated to the business day, in whichever form you've chosen. Revenue to revenue accounts, sales tax to a tax liability account, tips to a payable, discounts and comps as themselves, and cash and card tenders wherever you map them. Card tenders sit in whatever account you point them at until the money lands, then clear when you accept the deposit against them — the same click you already make in your bank feed, pointed at that balance instead of at Sales. Service charges map separately from tips, which matters more than it might seem: a mandatory service charge generally isn't a tip, and treating it as one understates your revenue.
Where your POS is also the card processor and reports its fee to Shogo, that fee posts as its own line, dated to the same day as the sales. Every posting is checked to balance before it's sent, and you can preview the entry before you activate it. After that it posts on its own each morning.
Yesterday's business, posted to yesterday's date, in balance, every morning. Not a deposit reverse-engineered into a guess at what you sold, and not eleven days of catching up.
You set it up once, and the daily rebuild goes away. If someone else keeps your books, this is the version of the day they'd rather receive than a stack of POS reports: already posted, already balanced, and dated to the day it happened.
Note: Want more from the same daily posting than a single revenue line? See how it carries segmentation by revenue center, daypart, and order source, and how the counts behind the dollars post as statistical accounts. Segmentation and statistical accounts both go furthest on Oracle NetSuite and Sage Intacct; on QuickBooks or Xero there's often more available than operators expect, with the right setup. Ask us what's possible.
Frequently asked questions
Can you record sales from your bank feed?
Technically yes — the deposit will categorize as income and the account will reconcile, which is why the habit survives. But a deposit records money arriving, not what you sold. Booking it as revenue overstates the top line by the sales tax and tips riding inside it, misses the cash that never went through the processor, and dates the revenue to settlement rather than to the day of business. Your bank agrees with your books, but your profit and loss statement is still wrong.
Why doesn't the bank deposit match the POS sales report?
The two numbers are never supposed to match. Between the sale and the deposit, processing fees come out, sales tax and tips ride along as money you owe rather than money you earned, gift card loads and redemptions move in opposite directions, cash settles on its own schedule through the safe and the bank run, and the card batch takes a day or more to clear — longer still for third-party delivery, which pays on its own cadence net of commission. The gap is the sum of those things, and it changes with the mix every day.
Should daily sales post as a journal entry, a sales receipt, or an invoice?
It depends on what you want your accounting system to report on afterward. A journal entry works on every system and is the only method that maps sales tax straight to a liability account, but journal entries don't feed your accounting system's product-based sales reports or its built-in sales tax reports, because those read from receipts and invoices. A summary sales receipt in QuickBooks, or an invoice in Xero, does feed them. An itemized version posts one line per item sold and takes the most setup to maintain. Shogo's guide to posting methods walks through the trade-offs.
What is a business day, and why does it matter for posting sales?
A business day is the operating day as your POS defines it, which usually starts at a set hour rather than at midnight. A bar closing at 2 a.m. rings sales after midnight that belong to the previous day of trading, and the POS records them that way. Posting on business dates keeps your ledger lined up with the shift reports and daily sales summaries your managers already work from. Posting on calendar dates splits those days in two, which shows up every weekend and at every month boundary.
Do you need a bigger accounting system to post sales daily?
No. Every major accounting system can carry a clean daily posting per location: revenue split by category, sales tax and tips on the balance sheet, fees visible as their own line, each tender routed to the right account. Each also gives you something to compare locations by: classes and locations in QuickBooks, tracking categories in Xero, segments in Oracle NetSuite, dimensions in Sage Intacct. The obstacle is rarely the platform. It is the fifteen or twenty minutes per location per day that building the posting by hand takes.