How to Keep Catering Deposits From Distorting Your Sales Forecast

Quick answer: give every catering job three dates and keep them apart: the day the customer pays you, the day your sales report counts the sale, and the day you actually cook and serve. Staffing, prep and purchasing run on the last one. Don’t change how payments are recorded to fix the forecast. Build a separate service-day view instead. Take each day’s report, pull out whatever catering money it counted that day, and keep what’s left as your ordinary sales line. Then add each catering event once, at its final total, on the day you serve it, as its own line, paid yet or not. Postponed and canceled events stay off that line. A served event stays on it even if money is refunded later. Track payments, balances and refunds separately, by event. Your books keep following whatever method your accountant uses. This view doesn’t touch them.

If you’re on Square, find out how the deposit was taken before deciding the report is wrong. Square’s help says a deposit on a Square invoice doesn’t reach Sales Reports at all until the invoice is paid in full, and then the whole invoice shows on the payoff date. If a deposit shows up as a sale on the day it came in, that isn’t what Square documents for invoice deposits. Check how it was taken and which report you’re reading. The test for that is below.

The Square help pages and forum post cited here were read November 1, 2026. The restaurant, events and numbers in the worked example are made up. Nothing here is tax or accounting advice.

Where the question comes from

On October 29, 2026, an operator who caters posted in Square’s Seller Community feedback board that catering money “posts to the day the payment is received,” not the day of the event. That throws off their staff’s forecasting. Their example was a deposit for a wedding in August 2027 that was recorded as a sale on the October day it arrived. The post doesn’t say whether the money was taken on a Square invoice, rung up as a regular sale or taken some other way, or which report showed it. Nobody had replied when we read it.

That missing detail decides the answer on the Square side. The forecasting fix below works either way.

The three dates

One event can have a different date in each column, and several cash dates if it’s paid in parts. The forecasting problem comes from reading the first or second date as if it were the third.

What Square documents, and what it doesn’t

• Invoice deposits wait for the payoff. Square’s help article on invoice deposits and payment schedules says sales on these invoices aren’t recorded in Sales Reports until the whole invoice is paid. The sale is dated to the day the invoice is paid off, not the deposit date or the day the invoice was sent. Once it’s paid, the invoice is marked Done and the amount shows as one line in the Sales report. Square’s article on creating and sending invoices says the same about invoices in general.
• Different screens, different days. The deposit article names three places in Square Dashboard. In Transactions, the invoice doesn’t appear until it’s paid off. The Sales summary doesn’t count it until it’s paid in full. In Savings, the partial amount appears on the day it was paid. Two people looking at “sales” can see the same deposit on different days.
• Canceling changes the report. The same article says that to refund a partial payment on an invoice that isn’t fully paid, you have to cancel the invoice. Partial payments on a canceled invoice then show in sales reports as a Custom Amount. That’s one more way a deposit can end up looking like a sale, so never cancel an invoice to tidy up a forecast.
• The service date field isn’t a reporting switch. When you create a one-time invoice, Square’s help lists an optional service date next to the due date. Neither article says that field changes which day Sales Reports use. Both say the sale follows the payoff date. Fill it in anyway. It puts the event date on the invoice, where you can copy it into your catering log.
• Payoff date isn’t service date either. If the customer pays the balance a few days early, the whole event lands on that earlier day. If you bill after the event, it lands later. Even when deposits are recorded exactly as documented, the report date matches the service date only when the last payment comes in on the day of the event.
• What the pages don’t settle. They don’t cover every way to take money in Square, how other reports or exports treat a partial payment, or what happened in any one seller’s account. The deposit article also has a note on how partial payments show in a transfers report that we couldn’t read clearly, so we’ve left it out rather than guess. We haven’t tested any of this in a Square account.

Find out what your report is counting

Pick one day when catering money came in and the report looked high. Pull two things: that day’s sales in the report you forecast from, and every catering payment you took that day, with the amount and how it was taken (invoice deposit, invoice balance, regular sale at the register, payment link, or something else). Find the catering money inside the day’s report, by item, invoice number or that day’s transaction list. Compare it with the payments you took that day, and with the full total of any invoice paid off that day.

The service-day view works whichever answer you get, because the event dates come from your own catering log, not from the report. The report only tells you what to take out of each day.

A worked week (fictional)

Millbrook Kitchen is a made-up restaurant that also caters. Every amount is before sales tax and tips, and card fees are left out. The forecast week runs Monday, May 31 to Sunday, June 6, 2027. Four catering jobs touch it.

We don’t know how your report treats deposits, so here are two versions of Millbrook’s report for the same week:

• Report 1 works the way Square documents invoice deposits: only payoffs count. Event A is paid off on Tuesday, so the full $4,800 shows on Tuesday. Nothing else is paid off this week. Event B’s $650 shows up on June 9, the following week.
• Report 2 counts each payment on the day it’s taken, which is what you’d see if, say, deposits were rung up as regular sales: $500 on Monday, $3,600 on Tuesday, $400 on Thursday.

Ordinary sales means dine-in, takeout and delivery: everything that isn’t catering. Millbrook’s service-day view for the week is $18,350 of ordinary sales plus $5,450 of catering served, $23,800 in all, with the two lines kept separate.

Look at what the reports would tell whoever writes the schedule. Report 1 makes Tuesday the biggest day of the week at $6,840 and Saturday an ordinary $3,560. The kitchen’s real heavy day was Saturday: a normal Saturday’s service plus a $4,800 wedding. Report 2 puts $5,640 on Tuesday too, and adds deposits to Monday and Thursday for two events that didn’t happen that week. Build next June’s schedule from either one and you staff up for the wrong days.

Check 1: each event, as of the week’s close

Do this by event, at one cutoff: here, the close of Sunday, June 6. Service and money are separate questions. Was it served, and when? How much has been received so far, and how much is still due? Received plus still due should equal the event’s total. An event can be served and still owe money, or paid and not yet served.

• A: served June 5. Received by the cutoff: $1,200 + $3,600 = $4,800, so $0 is still due. Report 1 counts $4,800 once, on June 1, the payoff day. Only $3,600 came in that day, but the entry matches invoice A’s $4,800 total and both payments on it, so it’s explained. Report 2 counts $1,200 in May and $3,600 on June 1, also $4,800. The service-day view counts $4,800 on June 5. Every view totals $4,800 over the life of the event. Only the dates differ.
• B: served June 2. Received by the cutoff: $0, so $650 is still due, and $0 + $650 = $650. That’s a normal gap, not an error. B stays in this week’s catering served, and the service-day view has it a week before the money. When the $650 comes in on June 9, still due drops to $0 and Report 1 shows $650 that day. Pull it out of that day’s report. Don’t add B to the service-day view a second time.
• C: $500 received and $0 served. Its service status is postponed, so it stays off the catering line, and the $500 has no service to match it to yet. It goes on an open list as “postponed, $500 deposit held” until it’s served, rescheduled or settled under your terms. Whether a deposit is refunded or kept, and how it’s recorded, is for your contract and whoever keeps your books.
• D: confirmed, not yet served. $400 received and $1,200 still due on the quote, for a June 26 event. It goes into the forward plan for June 26 at the quoted $1,600, marked as a quote until the final count is in.

A refund doesn’t undo service. Say part of B’s $650 is refunded after a complaint. The kitchen still staffed, prepped and bought for the lunch, so keep it on June 2’s catering line at $650, marked served. Log the refund on B’s money side as its own item, and leave how it shows in the report and how it’s recorded to Square support or whoever keeps your books. Same for a full refund or a dispute. Don’t delete the event or change its service date.

Check 2: the week bridges

From Report 1: $23,150 − $4,800 of catering the report counted this week = $18,350 ordinary. Add the $5,450 of catering served and you get $23,800.

From Report 2: $22,850 − ($500 + $3,600 + $400 = $4,500) = $18,350 ordinary. Add $5,450 and you get $23,800.

B’s $650 is in the $5,450 even though none of its money had come in by Sunday.

Both reports land on the same ordinary line and the same service-day total. If yours don’t, the report counted a catering payment that isn’t in your log, or your log has one the report didn’t count. Find it before you go on.

The double count to watch for

The easy mistake is adding the events to the report without first taking out what the report already counted. From Report 1, $23,150 + $5,450 = $28,600. That’s $4,800 too high, because the wedding is in the week twice: once on Tuesday and again on Saturday. From Report 2 you’d get $22,850 + $5,450 = $28,300, $4,500 too high. And if May’s history still holds the $1,200 deposit as a May sale, the wedding has been counted as $1,200 + $3,600 + $4,800 = $9,600 for a $4,800 event. The rule: catering comes out on its report date before it goes back in on its service date.

Build the service-day view

1. Keep a catering log by event. For each event: a short event code, the service date, a service status (quoted, confirmed, served, postponed, canceled, unknown), the final or quoted total, and each payment with its date, amount and how it was taken. Keep the money status separate: received so far, still due, and any refund or dispute. Add the report date when you see the payment show up. Use the event code, not the client’s name, in anything you share with the team.
2. Each day, split the report. Ordinary sales = the day’s report total minus the catering the report counted that day, whatever form it took: a deposit, a balance, a full invoice or a custom amount.
3. Add catering where it was served. Put each event’s final total on its service date, and only once it’s marked served. Paid or not doesn’t matter, and a later refund or dispute doesn’t take it off.
4. Forecast the two lines differently. Forecast ordinary sales from the history of the ordinary line, by day and service period. If you’re still building that forecast, how many orders your restaurant needs walks through it. Forecast catering from the confirmed bookings by service date, not from history. Catering doesn’t repeat by weekday the way walk-in sales do.
5. Run both checks every week, as of the same cutoff. For each event, received so far plus still due equals its total; flag refunds, disputes and cancellations instead of forcing a match. Each full invoice in the report matches its total and all its payments to date. And the week bridges from the report to the service-day view.
6. Leave the payment records alone. The view is a separate schedule. Nothing in it is entered back into the POS.

If daily totals look off by a few hours rather than by a whole payment, check what hours your report covers first. Square close of day report hours covers that.

What this doesn’t change

• Your books. The SBA’s guide to managing business finances describes the two common methods: accrual puts a sale on the books when it’s made, and cash only once payment comes in. Which one your business uses, how a deposit for an event you haven’t served is recorded, and anything to do with tax are your accountant’s call. The service-day view is a management schedule for running the kitchen. It isn’t your revenue for tax or financial statements.
• Your POS records. Don’t cancel, refund, re-ring, backdate or delete a payment to make the report match the forecast. Square’s deposit article says partial payments on a canceled invoice show up in sales reports as a Custom Amount, so changing records to fix a forecast can leave the report harder to read than before.
• Your pricing. How big a deposit to ask for, whether it’s credited to the final bill, and what to charge for the event are a separate job. How to calculate a private-event minimum spend or room fee covers that, including why a credited deposit is part of the final bill, not money on top.

Copy this manager note

It’s written to work whichever way your report treats deposits. The example line uses Millbrook’s fictional numbers.

CATERING SERVICE-DAY NOTE
(management forecast only)

SCOPE
For staffing, prep and
purchasing. Not the books,
not tax. Reports and books
stay as recorded.

THREE DATES PER EVENT
Cash:    customer paid
Report:  report counted it
Service: we served it
Forecast uses SERVICE.

TWO STATUSES PER EVENT
Service: quoted, confirmed,
  served, postponed,
  canceled or unknown
Money: received so far,
  still due, and any
  refund or dispute
Money never changes the
service status.

EACH DAY
Ordinary =
  report total
  - catering it counted
Catering served =
  final totals of events
  SERVED that day,
  paid or not
Keep the two lines apart.

EACH WEEK, AT ONE CUTOFF
[ ] Each event:
    received so far
    + still due = total
    (paid off: due = 0)
[ ] Each catering amount
    in the report matches
    a payment taken that
    day, or a full invoice
    paid off that day
    (invoice total = all
    its payments so far)
[ ] Report - catering
    counted = ordinary
[ ] Ordinary + catering
    served = service view
[ ] No event in twice
    (report day AND
    service day)

Example (fictional):
  23,150 - 4,800 = 18,350
  18,350 + 5,450 = 23,800
  Served, unpaid at cutoff:
    0 + 650 due = 650

STATUS
Served    -> catering line,
  even if paid later or
  refunded later
Confirmed -> forward plan
  (quote until final count)
Postponed, canceled
          -> open list,
             not served
Unknown   -> stop and ask
Late payment for a served
event: due drops to 0.
Don't add the event again.

STOP AND ASK IF
- Report shows catering
  that matches no payment
  and no paid-off invoice
- Received + due doesn't
  equal the total, and no
  refund or dispute
  explains it
- How it was paid is
  unknown
- Money refunded or
  disputed, or invoice
  canceled: ask support
  or books about the
  money. Keep the
  service record.
- Anyone suggests changing,
  refunding or backdating
  a payment to fit the plan

NEVER IN THIS NOTE
Card numbers, guest names
or contacts, logins

When to stop

• The catering money in a day’s report doesn’t match a payment taken that day or the full total of an invoice paid off that day, or you don’t know how a payment was taken. Find the transaction first, using its invoice or transaction number.
• An event’s received plus still due doesn’t add up to its total, and no refund, dispute or cancellation explains it.
• You don’t know whether an event was served. Find out before it goes on either list.
• An invoice was canceled, refunded or disputed, or a payment is still processing. Don’t assume where it lands in the report. Ask Square support or whoever keeps your books. If the event was served, it stays on the catering line while the money gets sorted out.
• Anyone suggests canceling, refunding, re-ringing or backdating a payment so the report matches the schedule.
• Someone wants to know how deposits should be taxed or recorded. That’s a question for your accountant, not the forecast.

Related reading

For setting the price, deposit and minimum for an event, see how to calculate a private-event minimum spend or room fee. If you’re using a weekly P&L alongside this, explaining a weekly P&L without mistaking cash for profit covers why the bank balance and profit move separately. More short operator questions are in Answers.

Sources: Square’s help articles on invoice deposits and payment schedules and on creating and sending invoices, the SBA’s guide to managing business finances, and the Square Seller Community post dated above. All were read November 1, 2026. We haven’t tested any Square account, and nothing here is tax, legal or accounting advice for your business.