The delivery landed this morning and the cartons are on the dock. The customer's order is packed. But the receipt hasn't been keyed in yet, so SKU.io says you have zero on hand — and it refuses to ship. Until now, the only way out was to fix the paperwork first while the customer waited, or to let a sales channel ship it behind SKU.io's back and quietly lose track of the stock. Inventory debt replaces that with a deliberate choice: ship it now, record exactly what you owe and what it will roughly cost, and let the next receipt settle the difference — automatically, oldest debt first — with your books correct at every step in between.

Closing a month has always been the part of the books that lives outside the software. You check the ledger reconciles, chase the entries that never synced, glance at inventory against the GL, export a few reports for the file — and then hope nobody posts into the month afterwards. None of that was written down anywhere, and nothing stopped a late invoice landing in a month you had already reported on. Month-end close turns that routine into a workspace: a checklist that grades the month's data for you, a sign-off that records what you accepted and why, and a lock that freezes the figures you approved as the month's numbers of record.

A supplier sends you a credit note for goods you are keeping — they overcharged you, or they gave you a volume allowance after the fact. The credit should lower what you owe them and lower what those goods cost you. Until now a vendor credit could only do the first part: the stock stayed on your books at a price you never paid, and the only way to fix its cost was to edit the original purchase order or bill — which erased the credit note from your records. Vendor credit cost impact closes that gap. Every line on a credit now states what it does to the goods, a Reason for credit picks the right behaviour for you, and a Cost Impact panel shows the real numbers — which receipts change, how many units are still on hand versus already sold, and what moves on the books — before you click Authorize.

Payment terms used to be a purchasing-only idea in SKU.io — something you agreed with a supplier, not something you could set for the people who buy from you. So the sales side had no answer to two questions every business asks: when is this customer supposed to pay? and how much are we willing to let them owe before we stop shipping? Payment terms and credit limits answer both. Terms now work in both directions from one shared list, every customer can carry default terms and a credit limit, and you get a live picture of what each one owes against the room they have left. Turn on credit enforcement and an order that would take a customer past their limit is held in Reserved instead of quietly shipping.

Plenty of products aren't made in one place. You send ingredients to a co-packer who cooks and blends them, truck the result to a second vendor for filling and pasteurizing, and land the finished cases at a 3PL — three vendors, two hand-offs, one product, and you own the goods the entire way. Until now, modelling that meant inventing the whole structure by hand: a work-in-progress SKU per hand-off, a recipe per stage, lot-tracking flags on every node, contractors, and a production order for each leg — roughly 25 minutes of setup, with several places to get the cost model quietly wrong.

Multi-stage co-manufacturing turns that into one guided flow. Tell SKU.io who does what and what they charge, and it builds the intermediate products, the per-stage recipes, and the vendor terms in a single transaction — then keeps them honest every time you run it.

Your accountant plans cash flow from your accounting file — and until the supplier's invoice arrives, an open purchase order is invisible there. You have committed the money, the goods are on their way, and the books show nothing. For businesses ordering weeks ahead of delivery, that gap can hide a large slice of upcoming spend.

Committed-spend billing closes it. Turn it on and every purchase order you submit posts a bill for its unbilled amount right away, so committed inventory spend appears in your books the moment you commit to it. Each committed bill then looks after itself: it shrinks as real supplier invoices are recorded against the order, and disappears entirely once the order is fully billed.

If you buy or sell in more than one currency, keeping exchange rates accurate used to be a manual chore — someone had to remember to update the conversion for each currency, and a rate that quietly went stale skewed your margins, costs, and reports. Automatic Daily Exchange Rates takes that job off your plate: SKU.io now pulls fresh rates every day and keeps every currency current, converted to your base currency automatically — whatever that base currency is.

If you sell on eBay, you know the pain of month-end reconciliation. An eBay Managed Payments payout is a single net deposit that quietly bundles your gross sales, refunds, final value fees, ad fees, shipping-label costs, and adjustments — so the number that lands in your bank is none of your revenue figures. Matching it back to your books by hand takes hours, and coding the whole deposit to one income account quietly misstates your revenue, fees, and tax.

eBay Payout Accounting fixes that. SKU now pulls your eBay Managed Payments payouts, breaks each one into its real components, and posts a single deposit-matched summary to your accounting — one entry that reconciles to your bank deposit to the cent.

You could always see a customer's orders — but never, in one place, how much they owed you, how overdue it was, or how to go about collecting it. Chasing payment meant exporting to a spreadsheet, hand-building a statement, and sending it from your inbox, all outside SKU.io. The customer page is now an accounts-receivable command center — it opens on money owed, breaks the balance down by how overdue it is, produces a real statement of account, and lets you email that statement or a payment request without leaving the page.

When a customer checks out with an offline payment method — a bank transfer, a purchase order, a "pay on delivery" — the order lands in SKU.io unpaid, yet until now it behaved exactly like an order you'd already been paid for: it allocated your stock immediately and could sail straight through to fulfillment. So a wire that might never arrive could quietly tie up inventory for weeks, and there was no way to say "hold this until the money's in." The new Unpaid Orders settings let you decide, per sales channel, exactly how an unpaid order is handled — bring it in as a held reserve with an automatic expiry, park it as a draft for review, or treat it as open and let it ship — with per-payment-method overrides and control over when it reaches your accounting software.