Transactions

A transaction is a movement of money, not a sale. Every payment taken at a POS terminal writes one row here, and that row is what you check the cash drawer against.

One order can produce more than one row when a payment is split across methods.

Go to AtubAgency Plugins → MultiPOS → Transactions.

Column	What it shows
ID & Date	The transaction number and when it happened
Staff Attribution	The outlet and the cashier
Transaction Context	The payment method, the order number and a reference
Financial Totals	In and Out

ID & Date and Financial Totals are sortable.

The two figures are the whole point of the screen.

• In is what the customer handed over.
• Out is the change given back.

On a sale, Out is only ever filled in for cash. The plugin records change only when the payment method’s slug is exactly cash. Every other method records Out as zero, which is correct. No change leaves the drawer on a card payment.

Two other kinds of row also use Out: a refund taken in the POS, and a manual cash-out. Both are covered further down.

So a 100 sale paid with a 120 note reads In 120, Out 20. The same sale on a card reads In 100, Out 0.

Total In minus total Out on the cash rows is what should physically be in the cash drawer, on top of the opening cash.

Because the transactions list tests for the literal slug cash, renaming that payment method’s slug stops change being recorded and quietly breaks the drawer check.

Change the label as much as you like. Leave the slug alone.

The slug column on that tab is read only for exactly this reason. It is generated once and then locked, so a past order’s payment method never stops resolving.

Two date fields sit above the table.

Set From and To, then click Filter. A Reset button appears next to it once a filter is applied.

Set both to the same day for a single shift.

The dropdown lists every user who can open the POS. Each carries their ID and email, so two people with the same first name stay apart.

Combine it with the date filter and you have one person’s shift, which is exactly the view you want when a drawer does not balance.

Tick rows and pick Delete.

The same figures, for today only, on the terminal’s Statistics screen.

Expected Drawer Amount is the running total a cashier counts against at the end of a shift. Your transactions list is the record behind it.

Where the refund was made decides whether it appears here.

Refund made from	Transaction row
The POS terminal’s Refund button (Pro)	Yes, amount under Out, method Refund
The WooCommerce order screen in the admin	No

A POS refund writes its own row, so Expected Drawer Amount already has the cash taken off and the drawer does not look short. See How to Refund an Order.

An admin refund does not, which is worth knowing if your office refunds by email while the shop counts a drawer. The stock still goes back correctly either way, including to the right outlet on a per-outlet stock store.

Money that moves in or out of the drawer outside a sale needs a manual transaction. Add one with the plus icon above Today’s Transactions on the terminal’s Statistics screen.

Those rows carry Manual in the Method column and an empty Order column, and Expected Drawer Amount counts them. Manual transactions are Pro; see How to Record Cash In and Cash Out.

This screen is where you confirm a manual transaction landed. The terminal does not show the row in the session that created it, so a cashier sees no change on screen. The row is here as soon as it is written. Tell staff to press Add once and check with you, not to press it again.

In the free version nothing here can be added by hand, so keep a paper or spreadsheet record of cash moved outside a sale.

• How to Close the Cash Drawer
• Orders for the sales side.
• Payment Methods for what fills the Method column.