Summary
Shogo loads each store's completed sales after the business date has closed, normalizes them, and builds a single accounting entry. That entry reflects what Revel reported for that date at the time of the load.
Revel allows changes to a closed business date after it has been finalized. A check can be voided the next day, a refund can be issued later in the week, and item or product configuration can be edited retroactively. When that happens, Revel's own reports recalculate. The accounting entry Shogo built for the original date does not.
This results in one of two outcomes:
- The date is out of balance (OOB) and will not post. Shogo requires that a date's payment total equal its item and tax total. A retroactive change that removes money from one side without removing it from the other breaks that balance, and Shogo holds the date rather than post an unbalanced entry.
- The date posted, but Shogo and Revel no longer agree. The entry was correct when it posted; Revel's figure for that date has since moved.
Both are resolved by you, in Shogo and in your accounting system. The options below are yours to choose between — which one is least work depends on whether the date has posted and whether the amount is material to you.
If the date is out of balance and has not posted
Use the Override report to plug the difference. The Override report lets you post an out-of-balance date with the variance carried as a balancing amount, so a stuck date does not hold up the close.
- Open the Override report for the affected store and locate the out-of-balance date.
- Before overriding, load the Revel report for that date and compare it to Shogo's totals, so you know what variance you are accepting.
- Apply the override. The date posts with the difference included.
- Note the amount and date so it is traceable at period close.
If the same variance recurs at a predictable, small magnitude, the POS Data Discrepancy tolerance setting can absorb it automatically rather than requiring an override each time. See What is OOB and how do I fix it? in the knowledge base.
If Shogo has already posted
The entry is in your general ledger, and Shogo will not rewrite a posted entry. You have two options.
Option A — Top-side adjustment. Book an adjusting entry in your accounting system for the difference, dated according to your own period-close policy, and attach the Revel report for the affected date as support. This leaves the Shogo entry alone.
Option B — Reload the date. Use Load/Reload Sales & Regenerate Accounting to reload the date from Revel and rebuild the entry from current data.
A reload is not guaranteed to resolve this. It reloads whatever Revel reports for that date today, which in many cases still contains the same imbalance — so the date can come back out of balance and then need an override to post again. That can end up being more work than a top-side adjustment, not less. It is also possible for the reload to clear the problem cleanly. Reloading is quick, so trying it first is reasonable; just be aware you may end up doing the override and the adjustment anyway.
If the variance is immaterial, doing nothing is also a legitimate choice. It will be absorbed in your normal reconciliation.
Shogo does not provide accounting advice, and materiality is your judgment. Where the change spans a closed period, coordinate the correction with whoever owns your close.
Note: If Rolling Reload is enabled for your store, recent dates are reloaded automatically on a trailing window. A retroactive change in Revel inside that window may change a date on its own, including one that has already posted.
Preventing the problem
These habits keep Revel and Shogo in agreement, and all of them are within your control.
Correct transactions before the business date closes. Voids, comps, and corrections made on the same business date as the original order are captured in the single daily load and never create a discrepancy. This is by far the most effective change.
Close all open checks before end of day. An order still open when the date closes may be attributed to a different date than you expect.
After a date has closed, refund rather than void. A refund or return records a negative tender on the day the money actually moves. That is a complete, balanced transaction, and Shogo posts it cleanly to that later date. A void on a closed date removes the sale with no corresponding money movement, which is precisely what breaks the balance.
Do not edit items retroactively. If a product was set up incorrectly — wrong class, category, or department — editing the product changes how its past sales are classified. Create a new item, or correct the mapping in Shogo going forward, rather than editing an item that already appears on closed dates.
Verify your business day start time. If your operating day rolls over at a time different from the default, late-night orders can land on the wrong business date. See Setting Up a Store's business hours in Shogo. Worth verifying if you run significant late-night volume.
A note on comparing Revel reports
Shogo reconciles at the order level using Revel's order data for the business date. Revel has advised that its Sales Summary and Order History reports can legitimately differ from one another when orders remain open across reporting periods.
If you are comparing Shogo to a Revel summary report and see a variance, compare at the order level first. The two Revel reports may not agree with each other either, and the order-level view is what will tell you whether a specific order moved dates or changed after the fact.