Who this is for: studio operators (admin panel) · Product: Podyx V2

Purchases is the money view of your studio. Where Sessions shows you the operational side, who is booked and when, Purchases is the ledger of every transaction that has happened on your account. When your accountant asks a question, this is the tab you open.

Watch the Purchases walkthrough

Admin Panel → Purchases

Amounts are named the way they are named at checkout. Total price is Subtotal, and Total price (VAT) is Total. You will see those two names across the Purchases lists and detail pages, in Session details, and in the client's Purchase history.

The purchases CSV export uses the same names: its header row reads Subtotal and Total. The values and the column order are unchanged — only the header text is different.

⚠️ Anything that reads those files by column name needs updating: a spreadsheet whose formulas point at a named column, a Zap or other automation that maps the export, an accountant's import template. An export that silently loses a column mapping is the kind of thing nobody notices until month end. Run one export now and check whatever consumes it on the other side.

💡 Sorting Individual purchases by Subtotal or Total follows the amounts shown on screen, refunded bookings included — so the order of the rows matches the numbers in them.

A purchase nobody has paid yet reads Amount due rather than Amount paid. That covers a cash Pay Later booking waiting on your approval, a payment link that has not been paid, and a payment that failed.

A booking that was cancelled, declined or expired and was paid at the studio shows no amount due at all — not in the CMS, and not in the client's account. A cash booking that never happened used to show the client a figure they did not owe, which is the kind of thing that comes back to you as an awkward email. There is nothing to clear up: affected bookings read correctly now.

💡 The label itself now tells you whether money has actually arrived — something an Amount paid row showing a figure on an unpaid booking never did.

💡 On the Individual tab, the Approved and Declined filter chips appear only for studios that actually use Pay Later — including studios migrated from v1 that take cash. If you are card-only, those chips stay hidden rather than sitting there matching nothing.

Bookings made before 6 August 2026, and bookings carried over from the previous Podyx, show the tax that was genuinely charged at the time rather than a figure recalculated at today's rate. A staff booking from the previous Podyx no longer has tax added twice — a 120.00 booking with 20.00 tax reads 120.00, not 140.00 or 144.00 — and a previous-Podyx booking with a price override lists the tax paid on top of that price.

⚠️ These corrections apply to the bookings already affected, with nothing to backfill on your side. Figures on an old purchase may therefore differ from what you saw before, and from an export you took earlier. The figures you see now are the correct ones — if you are reconciling against an older export, that is the explanation for the difference.

💡 For the fuller explanation of how tax is worked out and displayed, see Tax, VAT & Currency — that article is the canonical home for it.

If a session was edited into a more expensive booking, paid for by card, and then cancelled, the purchase shows the correct refunded, remaining and paid amounts. Those three used to be able to disagree after exactly that sequence — which is the moment a client is most likely to be reading the numbers over your shoulder.

A refund taken through Square appears on the purchase as soon as Square accepts it, rather than hours later when Square has finished processing it. The record matches what you just did, so you are not left wondering whether a refund went through — or issuing it a second time.

A refund can be reported as successful by the payment processor and still fail later, most often because the client's card has since been closed. When that happens, Podyx takes the refund back off the payment's refunded total and alerts your studio, so the ledger stops counting money the client never actually received.

⚠️ If you get one of these alerts, the client has not been refunded. Contact them and arrange the refund another way — a bank transfer or a new card — then record what you did.

Some payments land after the booking they were for has already expired. Podyx refunds these automatically, and those refunds run promptly.

When a payment goes through after the booking has already closed, the client is told what actually happened — and is promised a refund only when one is genuinely on its way, rather than being shown a "Payment failed — retry" message that explains nothing.

⚠️ If an automatic refund of this kind fails permanently, your studio receives an email asking you to refund the client by hand. Treat that email as a to-do: the money is still with you until you send it back.

Open any purchase to see the full ledger entry: the transaction details, the Subtotal and the Total, the date and time of purchase, exactly what was bought, and the associated Stripe data. Session purchases show the net amount, tax charged, and tax-inclusive total. Add-on purchases show the same breakdown with tax and gross rows listed separately. It is the complete story of a single payment in one place.

💡 On a package booking whose only paid extra was later removed, the breakdown no longer carries a leftover row of zero figures — the extra simply drops out.

Inside Purchase Details, a session whose time has already passed is badged Completed — but only when the purchase itself is confirmed.

Previously the badge went by the clock alone, so a pending or expired purchase could show its sessions as having taken place. The record then read as though a session had been delivered when it was never paid for and may never have happened at all.

💡 Completed now means two things at once: the session actually ran, and the purchase behind it actually went through. That makes it something you can rely on when reconciling, rather than a date check you have to verify by hand.

A cancelled session's card on the CMS session page says that it was cancelled, so the status is visible there too and not only on the purchase.

When a booking was bought with a promo code, the purchase page shows the whole chain rather than just a final figure: the original price, the promo code used, the discount applied, tax, the total, any credits used, and the amount paid. You can see exactly how a number was arrived at without reconstructing it yourself.

⚠️ Subtotal is the price before tax and Total is the full price of the purchase with tax included — neither is what the client handed over. That figure has its own row: Amount paid, or Amount due where nothing has been paid yet. If you have been reading the Total as the amount collected, read Amount paid instead — on any purchase where credits were used, they are different numbers.

🔒 A redeemed promo code is shown in full only to team members whose role lets them manage promo codes. Everyone else sees the first two letters with the rest masked, for example SU******. The discount amount stays visible to everyone.

If a purchase has a generated invoice, you can download it straight from the purchase record. You can also view all invoices in one place and export them as a ZIP file, which is the fastest way to hand a month or a quarter to your accountant.

Export the purchase list to CSV for reporting, reconciliation, or anything you want to do in a spreadsheet outside Podyx. The money columns are headed Subtotal and Total; if a spreadsheet, automation or import template of yours still looks for Total price or Total price (VAT), point it at the new names.

Sessions answers "who is coming in." Purchases answers "what did we earn, from what, and has it been paid." Use the filters to separate one-offs, bundles and subscriptions, check statuses to find unpaid balances, read the amounts as Subtotal and Total — the same names used at checkout and in the CSV export — and re-point any spreadsheet or automation that still reads that export by the old column names, read Amount paid rather than Total when credits are involved and treat Amount due as money that has not arrived — a cancelled, declined or expired booking paid at the studio shows none — sort Individual purchases by Subtotal or Total knowing the order matches the figures on screen, trust the Completed badge in Purchase Details because it now appears only on a session that ran under a confirmed purchase, expect bookings from before 6 August 2026 and bookings carried over from the previous Podyx to show the tax actually charged — which may differ from an older export, and is the correct figure — act on any alert or email telling you a refund failed because those clients still need their money, and export invoices as a ZIP when it is time to do the books.

Related: Sessions · Invoicing · Payments & Refunds · Credits · Promo Codes