If you pay sales reps on commission, you have probably been doing the math somewhere else. Rates live in a spreadsheet, someone exports orders at the end of the month, and the two get reconciled by hand — every month, for every rep. It works right up until a rate changes mid-month, or someone asks which territory is actually carrying the number.

Sales rep commissions brings all of it into SKU.io. Give each rep a commission rate, group reps into territories or teams, and run the numbers over any date range you like. The orders are already here, so the calculation is just there — nothing to export, nothing to reconcile.

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.

The same physical part often lives under two SKUs: the official part number customers search for, and the identical equivalent you actually keep on the shelf. Until now those orders just stalled — the listed SKU sat backordered while the interchangeable item was in stock a few feet away, and "fixing" it meant editing order lines by hand. Product substitutions links equivalent SKUs so those orders flow: swap a stalled line to the stocked substitute in one click, or select the whole backlog and release it at once. The customer still sees exactly what they ordered — the invoice and packing slip keep the original SKU — while the pick list tells your warehouse which part to actually pull.

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.

Customizing your PDF documents — invoices, purchase orders, packing slips, quotes, credit notes — used to mean wrestling a word-processor-style editor that had its own ideas about your layout. Simple requests like "make the items table span the full page" were surprisingly hard, and anyone comfortable with HTML had to fight the editor's constant reformatting. The new PDF Template Editor replaces all of that with a proper split-pane workspace: your template's HTML on one side, a live PDF preview on the other, and a built-in Template AI assistant that can make layout changes for you from a plain-English instruction — "make the items table full width", "add a Supplier SKU column", "match a clean Stripe-style invoice". Every AI edit is validated, shown as a reviewable diff, and never saved until you say so.

If you sell on Magento 2 (Adobe Commerce), keeping your store and your inventory system in agreement has meant CSV exports, copy-paste order entry, and stock levels that drift out of date the moment they're published. The new Magento 2 integration connects your store to SKU.io as a first-class sales channel: orders, products, customers, and transactions flow into a dedicated workspace, SKU.io sales orders are created from Magento orders in bulk or automatically, and on-hand quantities push back to your store's inventory sources on a schedule.

Real business relationships are never one person. Your supplier has a sales rep who quotes, an AR specialist who chases invoices, and a shipping coordinator who books freight — but until now, SKU.io gave you a single "contact name" field and left the rest to sticky notes and inbox archaeology. Contacts replaces that flat field with a full contact book on every supplier, customer, and warehouse: unlimited people, each with a role, email, phone, title, and notes, one of them starred as the primary. Contacts show up right in your supplier, customer, and warehouse lists, flow through import and export like any other data in SKU.io, and their personal details are encrypted at rest.

If you buy or sell across a border, the Incoterm is one of the most consequential fields on the order — it decides who pays the freight, who insures the goods, who clears customs, and the exact moment risk stops being yours. Until now, SKU.io treated it as little more than a note: a free-text code on purchase orders, nothing at all on sales orders, and no explanation of what any of it meant. Incoterms changes that. The 11 official ICC Incoterms® 2020 rules now ship built into every account with plain-English education, a term on an order is a complete value — code, named place, and edition — that's locked into history, and every screen that touches a term can explain exactly who is responsible for what.

Until now, refunding a customer meant leaving SKU.io. Your CS rep would look up the order here — what shipped, what came back, what's already been credited — then open Shopify admin, or Seller Hub, or Seller Center, re-key the same line items and amounts into that channel's refund form, and hope nothing got transposed along the way. Every channel meant another login, another tab, another place a decimal could slip. Channel Refunds ends the round trip: pick the lines, quantities, and amounts right on the SKU.io sales order and the refund goes out to the channel itself — the customer gets their money back through the original payment method, and the matching sales credit lands in your books automatically, linked to the request that created it.