BTAB now runs the buy side end-to-end — and hands your books to Xero

If you sell through BTAB, the platform has always handled everything downstream of the sale: the storefront, the order, the payment, the payout. Everything upstream of it did not. The purchase order you send your supplier, the pallet that turns up two weeks later, the invoice that follows it three weeks after that — all of it lived in another system, behind another login, reconciled against BTAB by hand at the end of the month.

That gap is closed. Purchasing, receiving, supplier bills and both directions of money now sit in the same dashboard as your orders, and the whole thing is a loop you can walk from a screen.

It starts with how you hold stock

Buying only makes sense if you own the goods, so the first thing the dashboard asks is how you hold stock: owned, consignment or dropship. It's a setting, not an assumption — and it's overridable per supplier or per brand, because most merchants are a mix. You might own your core range and dropship the long tail from two suppliers. The setting resolves per line, so a single order can carry both.

Flip any relationship to owned and a Purchasing section appears in the nav. Stay pure dropship and nothing changes — no new menus, no screens full of things that don't apply to you. You'll find the switch under Settings → Stock model.

A purchase order that actually leaves the building

Cut a PO from the Purchase Orders screen: pick the supplier, search their catalogue, set quantities and unit costs, watch the total add up, save it as a draft.

Then press Send, and the supplier gets it. Not a status change on your side — an actual email in their inbox, with the PO number, every line with its quantity, unit cost and line total, the order total, the expected date, and whatever notes you added. Reply-to points back at you, so their answer lands where you'd expect.

There's no PDF attached, and that's deliberate. The email is the purchase order — the same call we made on tax invoices. The person reading it is usually reading it on a phone in a warehouse, and a document you have to download and open is a document that gets read later, or not at all.

Receiving, including the messy kind

Goods rarely arrive the way the PO described them, so receiving assumes they won't. Each line shows what was ordered against what's already arrived, and the receive form defaults to whatever is still outstanding — accept it, or type what actually turned up. Partial receipts are a first-class case, not an edge case; you can receive the same PO four times across a month and every receipt is kept in the goods-receipt history with its date and the landed cost it carried, while the lines table keeps the running received total.

On-hand moves as you receive. If a product was never stock-tracked before, the screen tells you plainly that this first receipt will set its count rather than add to it — a silent overwrite of an inventory number is exactly the kind of surprise that turns into a support ticket a fortnight later.

Freight, duty and the other costs that make an item cost more than its invoice line are captured at receipt and shown against the receipt that carried them. Exchange rates are frozen at that same moment, because receipt is the point the cost becomes real. One number, fixed once, rather than two plausible numbers that disagree.

The bill has to agree with the goods

A supplier's invoice is a claim, not a fact. When you capture a bill you can anchor it to the purchase order it belongs to, and the claim gets checked against what you actually agreed and actually received. Linking seeds the billed lines from the PO — quantities default to what you actually received where anything has arrived, otherwise to what was ordered — and the unit costs come across from the PO.

Then every line is checked, and gets a badge:

• Matched — the price is within 2% of what you agreed, and you weren't billed for more than arrived. Full three-way agreement between the order, the receipt and the bill.
• Variance — something doesn't. The supplier billed a price you didn't agree to, or a quantity you didn't get. Flagged for a human.
• Unmatched — a leg is still missing; the check can't be completed yet.
• No PO — a standalone bill with nothing to match against. Recorded, and honestly labelled as unverified.

If your supplier invoices on dispatch and nothing has physically arrived yet, we don't hold that against them — the quantity check simply isn't applied rather than reporting a variance against zero.

The point isn't that the software approves your bills. It's that it tells you which lines you shouldn't approve without looking at them.

Both directions of money, read the same way

Two screens, deliberately identical in layout, because they answer the mirror-image question:

• AP Aging — what you owe, per supplier, in Current / 1–30 / 31–60 / 61–90 / 90+ buckets, overdue tinted.
• AR Aging — what you're owed, per customer, in exactly the same buckets.

They diverge on what you do next. AR Aging expands: click a customer to see the individual invoices behind the balance, and mark one paid when it settled outside the platform — a bank transfer, a cheque, cash over the counter. AP Aging is a flat read; you record payment against the bill itself, where it lands on an append-only ledger that walks the bill from part-paid to paid. The AR screen isn't behind the stock-model gate, incidentally; it's sell-side, so it's there whether you hold stock or not.

Alongside it, customers now carry an account type, credit terms and a credit limit, and a customer enquiry can be priced into a quote and converted straight into an order — so the account you invoice is the same record the aging screen reports on.

And then it goes to Xero

Every supplier bill carries a GST treatment, and BTAB is careful with it: taxable maps to GST on Expenses, GST-free to GST Free Expenses, an internal transfer to BAS Excluded. Anything it doesn't recognise falls back to BAS Excluded rather than guessing. And a taxable bill from a supplier with no ABN on file claims no input tax credit at all — without a valid tax invoice there is nothing to claim. We'd rather hand your bookkeeper a conservative number they can adjust than a confident one they have to catch.

Two exports are live now, in Xero's own invoice-import shape, for any date range: sales as ACCREC with tax-inclusive amounts, and bills as ACCPAY with tax-exclusive amounts, because that's how each side is actually stored. Your bookkeeper imports them in minutes.

Behind the exports sits the direct connection, already built. Once it's switched on, an approved bill posts itself into your connected Xero organisation as a draft ACCPAY invoice, with the Xero invoice ID stamped back so the same bill can never be pushed twice. Draft is the point — your bookkeeper approves things in your ledger, not us. And the CSV exports aren't going away when it lands: a file your bookkeeper can keep is its own kind of audit trail.

What we're not building

BTAB has no general ledger, no chart of accounts, and no BAS. That isn't a roadmap gap we're embarrassed about — it's the line, and we intend to stay on this side of it.

Xero owns your ledger. BTAB owns the documents that feed it, and the operational truth behind them: what you ordered, what arrived, what the supplier billed, whether those three agree, and what's outstanding in either direction. Software that offered to do both jobs would be asking you to keep two sets of books and then trust it to keep them identical. We'd rather hand a clean, checked document to the system your accountant already knows.

Where to start

Settings → Stock model. Set your default, add an override for any supplier you buy outright, and the Purchasing section appears. From there it's one loop: cut the PO, send it, receive what arrives, capture the bill against it, look at anything the match flags, and export the period when your bookkeeper asks.