At 8 p.m. on a busy Friday, the POS says the shop sold $3,842. The staff also accepted two trades, issued $510 in store credit, paid $325 cash from the safe, moved $600 from a drawer to the safe, seated 28 players for an event, and promised three customers that their pickups would be ready Saturday.
The sales total is correct. It simply does not describe the whole shop.
Give each fact one owner
A clean boundary starts by deciding which system is authoritative for each business fact.
| Question | Best source |
|---|---|
| What products were sold? | POS |
| How was a sale tendered? | POS or payment provider |
| What did the processor settle? | Payment provider and POS reconciliation |
| Which cards did the shop agree to buy? | Trade Desk |
| Why was the offer above policy? | Trade approval history |
| Why did a customer's credit change? | Store-credit ledger |
| Which physical account funded a cash trade? | Money ledger |
| What should the next shift finish? | Operations work queue |
| Which release quantity is promised to customers? | Release and preorder record |
| Who can act at this location? | Employee roles and location access |
The same event may create connected records, but one system should own each answer.
Walk through one accepted trade
Suppose a customer brings in a binder with an estimated resale value of $600. Shop policy produces a $360 cash option and a $420 store-credit option. The customer chooses store credit.
The operational record should show:
- customer and receiving employee;
- binder or lot description;
- estimated resale value;
- cash and credit recommendations;
- approval when the offer exceeds policy;
- customer decision;
- one accepted settlement;
- the created store-credit ledger entry;
- optional handoff to inventory receiving.
The POS may later record purchases where that credit is used. It should not be the only place the shop tries to preserve how the $420 was earned.
Walk through one cash payout
For a second trade, the customer accepts $325 cash. The bills come from the main safe because the event-night drawer needs to stay funded.
The operations and money records should preserve:
- accepted trade ID;
- $325 payout;
- Main Safe as the physical source;
- employee who handed over the cash;
- approval and reason if needed;
- business date and time;
- correction link if the payout is later reversed.
Entering a generic $325 Pay Out in the POS can help drawer math, but it does not replace the trade record. The trade record should also reference the money movement so employees do not post it twice.
Reconcile the handoff, not every screen
The goal is not to make two systems show identical dashboards. Reconcile where value crosses the boundary.
For the Friday example:
- Start with POS cash sales for the active drawer.
- Add or subtract cash refunds recorded through checkout.
- Include trade payouts and other paid-outs from that drawer.
- Include cash moved to or from the safe.
- Compare expected drawer cash with the blind physical count.
- Keep card sales and processor settlement out of physical-cash math.
If the safe funded a trade, do not subtract it from the front drawer merely because both happened on the same business date.
Keep store credit separate from tender and cash
Store credit is a customer liability, not cash sitting in a drawer.
The store-credit ledger should explain issuance, redemption, correction, and reversal. The POS can record that a sale used store credit, but the shop still needs a consistent way to connect that redemption with the customer's balance history.
Do not add a $420 credit issuance to cash-in. Do not describe a $200 credit redemption as a bank deposit. These records answer different questions.
Keep event operations outside the receipt
The POS can sell a $10 event entry. It usually does not answer:
- whether the player is registered;
- which event and start time they joined;
- whether capacity is full;
- who runs pairings;
- what product or prizes are reserved;
- which players require follow-up.
Connect the sale or payment reference when useful, but let the event record own the operational state.
Avoid four common duplicates
- Trade plus manual credit: accepting a trade issues credit, then an employee manually adds the same amount.
- POS paid-out plus operations payout: the same cash movement is counted twice in reports.
- Received plus expected stock: a preorder sheet treats an ordered quantity as physically available.
- Sale plus deposit: gross sales and processor deposit are both treated as separate revenue.
Each duplicate begins with a reasonable record. The mistake is treating both records as a new business event.
Use this system-boundary worksheet
For every shared workflow, write down:
| Field | Decision |
|---|---|
| Business event | What actually happened? |
| Authoritative system | Where is the official record? |
| Connected system | What reference or summary does it need? |
| Shared identifier | How do employees connect the records? |
| Reconciliation point | Which totals or postings must agree? |
| Correction authority | Where is a mistake fixed without duplication? |
The POS should remain excellent at sales. Operations software should make the rest of Friday night understandable after the receipts stop printing.