When Yesterday Isn't Ready: How Shogo Handles the Days That Don't Post Cleanly

Most mornings, yesterday's sales are in the books before anyone at a restaurant, hotel, or retail group has opened a laptop. Shogo pulls the prior business day from each location's point of sale, property management system, or online store (the source system, for short) and posts it to the general ledger. Some mornings, though, yesterday isn't finished. A check is still open. The processor hasn't reported the day's card fees. A new discount showed up that doesn't have an account. Sales and payments are $40 apart, and nobody knows why yet.

Those mornings matter more than the clean ones. A wrong number that quietly lands in the ledger tends to surface at month-end, when it's hardest to trace. This post walks through the situations that keep a day from posting cleanly, what Shogo does with each, and what, if anything, your team needs to do.

Why does Shogo hold a day instead of posting it?

Shogo holds a day when posting it would put a number that isn't right yet into the ledger, because finding and fixing a wrong number after it posts costs more than waiting a little for the right one. A posted day looks finished. It flows into reports, reconciliations, and closed periods. An error in a posted day stays hidden until someone happens to spot it, and by then it may already have been acted on. A held day is visibly unfinished. It sits in plain view with a reason attached, and the fix happens before the number reaches anyone.

Shogo waits rather than guesses. A day posts when its numbers are right, and a day that isn't ready says why.

What happens to open checks?

An open check is one that's still partly or fully unpaid when the business day ends: a bar tab left running or an order whose payment never went through. The sale happened, but the payment that balances it hasn't been recorded, so the day's sales and payments don't match. Shogo gives you two ways to handle it, and the right one depends on how your locations run.

The first is to let the day wait. Shogo holds it, retries on its own over the next several days, and posts the day as soon as the open checks are closed, with nothing for anyone to do. If a check is still open when the retries stop, someone can close it in the source system and reload the day, which has Shogo pull the day again. While the day is waiting, your team can also write the open amount off to an account they choose, and the day posts. That suits a check that can't be resolved or is too small to be worth chasing.

The second is to choose an account for open checks up front. The day then posts on time with the unpaid amount sitting in that account. This suits groups where chasing every open check at every location isn't realistic. Once a day has posted, Shogo doesn't look at it again, so if a check is paid later, reload that day to update its original posting.

What is a batch hold?

A batch hold happens when a day's sales post on schedule but the entry for the card deposit waits, because the processor hasn't yet reported the fees taken out of that deposit. It applies only when the processor nets its fees out of each day's card deposit and the source system reports that breakdown. If the processor bills its fees monthly instead, Shogo posts the card sales at their full amount, and batch holds don't come up.

The deposit that lands in the bank is the day's card sales minus the fees. Posting the deposit before the fees are known would mean guessing, and a guessed deposit won't match the bank. So Shogo splits the day. The sales go in on time, with the card amount parked in a clearing account. The deposit entry waits. Shogo retries periodically until the fee details arrive. Once they do, it posts the deposit entry on its own, which zeroes out the clearing account.

If the fee details still haven't arrived after several days, the deposit entry stays on hold until someone reloads the day. A location that goes on batch hold every single day is usually telling you something else: its processor isn't netting fees daily after all, and the location should be set up for monthly fees instead. For why the deposit is its own entry in the first place, see how daily sales posting and the bank feed record different things.

Something new, with nowhere to post

A day also waits when it contains something Shogo hasn't been told where to post: a new sales category, a new discount, a new way for customers to pay, a new tax. Each of these needs an account in your general ledger, and choosing that account is your team's decision, not the software's.

Shogo holds the day, names what needs an account, and waits. This is the only hold that can never resolve by itself, because nothing in the source system is going to change. Someone has to make the choice. Once they do, the held day posts automatically, and every later day that includes it posts on time without Shogo asking again.

What if the day doesn't balance?

A day is out of balance when its sales don't equal the payments recorded against them in the source system: a payment taken with nothing rung up, for example, or a refund recorded on one side and not the other. That's not the same as a cash drawer being over or short. An over/short is not an out-of-balance day.

Sometimes the source system sends incomplete data and corrects it later. Reloading the day brings in the corrected numbers, and the day posts. When the source system doesn't correct it, someone decides where the difference goes. Shogo posts that day's difference to whichever account you choose.

Small differences and real problems

Not every difference deserves a person's attention. A few cents of rounding is noise, and holding a day for it has its own cost. You can set a small daily tolerance for each location. Differences within the tolerance post automatically to a line named "POS Data Discrepancy," in an account you choose, and anything larger still waits for someone to look. The line stays visible in the ledger, so a tolerance that gets used every day is a signal worth reading.

A held day doesn't hold up the week

Each day is judged on its own, so one held day doesn't stop the days after it. Here's a week at one location where three of these situations came up:

Thursday posted on schedule while Wednesday was still waiting on its open check.

That's the difference between holding and stalling. The books stay current for every day that's ready, and the days that aren't are the only ones anyone has to think about.

Whenever a day posts, its entries carry that business day's date. Wednesday posted on Friday but is dated Wednesday in the ledger, not folded into Friday.

What does your team actually do?

For most held days, nothing. Shogo retries on its own until open checks close or card fee details arrive, and posts whatever was waiting once they do. Your team doesn't have to wait for the retries, though. A user can reload a day at any point, so a day someone has just fixed in the source system can post right away. The two situations that usually need a person are something new without an account and a difference your tolerance doesn't cover.

Every held day shows its status and the reason in Shogo. Shogo also notifies the users subscribed to accounting notifications, so nobody has to go looking. Before closing the month, run the status report across all locations. It lists anything that hasn't posted and why, so every held day can be resolved in its own period.

None of this changes with the ledger. Shogo handles held days the same way in all four general ledgers it posts to: Oracle NetSuite, QuickBooks, Sage Intacct, and Xero. Step-by-step instructions for each situation are in the Shogo knowledge base.