SKU.io Ops Calculators

Use this when a seller asks how a tariff or duty increase, or the end of a de minimis exemption, affects their margins, what a new rate they supply does to landed cost, or how much they would need to raise prices to keep their margin or profit per unit. Do not use to split an actual shipment's freight and duty, or to look up a tariff rate or HTS code. The user supplies the rates: either current and new duty rate columns per product, or one current and one new rate (as percentages) applied to every product. Needs products with SKU, unit cost and sell price; optional freight and other per-unit costs and annual units. Returns landed cost and margin before and after, the margin change, the price needed to keep the old margin percentage and the price needed to keep the old profit per unit, and the yearly cost increase when units are given. It does not know tariff schedules, HTS codes or which rate applies to a product. Read-only; stores nothing.

calculate_tariff_impact

Use this when an Amazon FBA seller asks whether Amazon reimbursed them for every lost or damaged unit, which lost or damaged units were never paid for, whether reimbursements covered their real cost, or which refunded orders were never returned to the warehouse. Needs the Inventory Ledger export (detailed view: Date, FNSKU, MSKU, Event Type, Reference ID, Quantity, Reason) and the Reimbursements report (reason, sku, fnsku, amazon-order-id, amount-total, quantity-reimbursed-cash and quantity-reimbursed-total). Optional: refunded orders (order id, sku, quantity, refund date), the FBA Customer Returns report, and unit costs per SKU. Returns, per SKU, units lost (reason M or 5), found (F) and damaged in Amazon's warehouse (E, 6, 7, Q), units already reimbursed and units possibly still owed; per refunded order, units with no matching return after 45 days (adjustable); each with an estimated value (unit cost, else the average Amazon paid per unit), the earliest event date, and totals of units and value possibly owed. It also flags SKUs Amazon paid below the user's unit cost. It estimates from the reports only and cannot see Amazon's own investigation or open cases; it does not contact Amazon. Do not use for settlement payout breakdowns, FBA fee overcharges or restock planning. This is not accounting or tax advice. Read-only; it only calculates from the data provided and stores nothing.

check_fba_reimbursements

Use this when a seller asks which products are dead stock, slow-moving or overstocked, which are at risk of stocking out, how many days of cover each SKU has, or how much cash is tied up in excess inventory. Do not use for inventory age or Amazon aged-inventory surcharges; it has no age data. Needs current stock (SKU, on hand, optionally unit cost) and either sales history or a units-sold-last-30-days column. Classifies every SKU as out of stock, at risk, dead stock, overstock or healthy, with days of cover and stock value when costs are given. Read-only; stores nothing.

check_inventory_health

Use this when someone in purchasing or accounts payable asks to check a supplier invoice against the purchase order, do a three-way match, or find what's wrong with an invoice before paying it: price differences from the PO, quantities billed but not received (short shipments), quantities billed above what was ordered, lines that aren't on the PO, duplicate lines, and PO lines not invoiced. Needs the invoice lines and the PO lines as CSVs or rows; receipt lines (what was actually received) are optional but needed to catch short shipments. If the invoice is a PDF or image, read its line items yourself and pass them as invoice_rows with item, quantity, unit price and line total. Optional invoice-level amounts (subtotal, total, freight, tax, and the freight the PO terms allow) are checked too. Returns per-line status, the approved amount, the amount at issue, and what the invoice comes to if the exceptions are held. It reports; it does not approve or reject payment. Read-only; stores nothing.

check_supplier_invoice

Use this when a seller is choosing between fulfillment warehouses (3PLs) and asks which quote is cheaper, what each 3PL would cost per month or per order, or how their rate cards compare for their order volume. Do not use for software quotes, or to check a 3PL's invoice against its rate card. Needs 1–6 rate cards the user has received (one row per provider per fee: provider, fee, amount, optional unit; or one row per provider with a column per fee) and the user's order profile: orders per month, units per order, B2B orders, inbound pallets/cartons/units, storage pallets/bins/cubic feet, returns rate and kitting. Prices every fee against that profile, applies monthly minimums, and returns monthly, annual and per-order cost per provider with a breakdown by fee category and any services a provider did not quote. Providers are only the ones the user enters; it never suggests, rates or ranks 3PL companies. Shipping is excluded unless the user includes it. Read-only; stores nothing.

compare_3pl_quotes

Use this when a business is comparing quotes for inventory, order management or ERP software and asks what each option really costs over time, which quote is cheaper over three years, what the total cost of ownership is, or how much cash goes out in the first 90 days. Do not use for fulfillment warehouse (3PL) quotes. Needs two to eight options the user is evaluating, each with the numbers from their own quotes: monthly subscription, users and per-user fee, per-order fee, implementation, data migration, training, one-time and monthly integration fees, add-on modules, payment or transaction fees, annual price escalator, contract term, and internal staff hours with an hourly rate. Returns total cost over 1 to 5 years, cost per order, year-by-year cost, first-90-days cash and a cost breakdown per option. It only uses numbers the user provides: it does not know, look up or suggest any vendor's pricing, and it does not recommend, rate or rank products, only their costs as entered. Inputs the user leaves out are counted as zero and listed as not provided. Read-only; stores nothing.

compare_software_costs

Use this when someone says their stock take, cycle count or physical count doesn't match Shopify, the inventory system or the 3PL, and asks what the variance is in units and dollars, how much shrink the count found, which SKUs are short or over, or which SKUs are missing from one system. Needs the counted quantities (SKU and counted qty, optional location) and the system of record's on hand (SKU and on hand, e.g. a Shopify inventory export); optionally a second system's on hand (a 3PL or FBA inventory report) for a three-way comparison, and unit costs from a cost column in any file or a separate cost list. Returns, per SKU (or per SKU and location), the counted, system and second quantities, the variance in units and dollars against each, and a status: matched, short, over, missing from count or missing from system; plus net and absolute variance in dollars, shrink and overage in dollars, and count accuracy (share of SKUs within the tolerance), largest variances first. Do not use for reconciling inventory value to the general ledger in QuickBooks or Xero, or for deciding what to reorder. This is not accounting or tax advice. Read-only; it only calculates from the data provided and stores nothing.

compare_stock_counts

Use this when a seller asks to turn a reorder list into draft purchase orders shown in the chat, split what they need by supplier, or round order quantities up to case packs and minimum order quantities (MOQs). Do not use to decide how much to reorder; it needs the quantities first. Needs what to order (SKU and quantity needed; a reorder plan's suggested order quantity works) and a supplier catalog (SKU, supplier, unit cost; optional MOQ, case pack, lead time days, supplier minimum order value). Raises each line to the MOQ, rounds up to whole cases, groups lines into one draft PO per supplier with totals, picks the cheapest supplier when several carry a SKU, and flags POs under the supplier's minimum and SKUs missing from the catalog. It drafts the POs only: it does not send, place or submit anything to a supplier. Read-only; stores nothing.

build_purchase_orders

Use this when an Amazon seller asks what the errors in their listing upload or listings issues export mean, the usual fix for error codes like 8541, 8560, 8572 or 90220, or which SKUs failed in a flat-file feed. Do not use for stranded inventory or account health. Reads the processing report or feed results downloaded from Seller Central (tab- or comma-separated, with or without the Feed Processing Summary lines), a listings issues export, or error lines pasted into the chat. Groups the results by error code or by SKU, explains each code it knows in plain English with the usual fix, and quotes Amazon's own message for any code it doesn't know rather than guessing. It explains reports the user provides; it does not connect to Seller Central or change listings. Read-only; stores nothing.

explain_amazon_listing_errors

Use this when an Amazon seller asks where their payout or disbursement went, why a payout is lower than their sales, to explain or break down their Amazon settlement, how much Amazon took in fees per SKU, or which SKUs made or lost money after Amazon's fees in a settlement period. Do not use for profit after product cost, for reimbursements Amazon may still owe, or for matching a payout to a bank or accounting ledger. Reads the settlement flat file (V2) from Reports > Payments, or the Date Range Report (transaction view) from Payments > Reports Repository, uploaded or pasted into the chat, and detects which one it is. Returns the payout broken into product sales, shipping credits, promotions, refunds, referral, FBA, storage, advertising and other fees, reimbursements and taxes, with each as a share of gross sales, or per SKU with view=by_sku. For a settlement file it checks that the lines add up to Amazon's reported total. Read-only; stores nothing. It explains the report and is not accounting or tax advice.

explain_amazon_settlement

Use this when a seller asks to forecast their sales or demand per product, how many units they will sell in the next weeks, months or season, or how much inventory to buy for Black Friday, Q4, Prime Day or another peak season. Do not use for a product with no sales history, or to set a reorder point from a supplier lead time. Needs sales history with SKU, date and quantity (a Shopify or Amazon orders export works); two years of history lets it learn seasonality, less falls back to trend or average. Current stock (on hand, optionally inbound) is optional; with it the tool also says how many units to buy and which SKUs to buy now. Returns per-SKU weekly-based forecasts for the horizon and an optional peak window, the method used for each SKU, and a buy plan. Statistical forecasts from past sales only, not guarantees. Read-only; stores nothing.

forecast_demand

Use this when an Amazon seller asks how many units to send or ship to FBA, what to put in the next inbound shipment, how their own number compares with Amazon's restock recommendation, or which SKUs will run out at Amazon before a shipment arrives. Do not use for reorders from a supplier (use plan_reorder_points), FBA capacity limits or AWD. Needs FBA inventory (SKU, available, optionally inbound) and either sales history or a units-sold-last-30-days column. Returns per-SKU units to send, rounded up to the case pack, and flags SKUs that will stock out before a shipment sent today lands. Read-only; stores nothing.

plan_fba_restock

Use this when a seller asks when to reorder, how much stock to buy or reorder, what their reorder point or safety stock should be, or which SKUs will run out before a new purchase order from the supplier can arrive. Do not use for a seasonal or peak-period forecast, for grouping quantities into supplier purchase orders, or for units to send to Amazon FBA (use plan_fba_restock). Needs sales history (order lines or daily sales with SKU, date, quantity) and the supplier lead time in days. Current stock is optional; with it, the tool says which SKUs to order now and how many units. Returns per-SKU average daily sales, variability, safety stock, reorder point, order-up-to level and suggested order quantity. Read-only; stores nothing.

plan_reorder_points

Use this when a buyer or owner asks how much they owe suppliers next week or next month, what cash goes out each week for their open POs, when deposits and balances fall due, or what their supplier payment schedule looks like across 30/70 deposits, balances before shipping and net 30/60/90 terms. Needs the open purchase orders (supplier, PO number, total value, payment terms as text, and the PO date, ship or FOB date and ETA; currency optional) and, optionally, the payments already made (PO number, amount paid, date). Reads terms like 30/70, 50/50, 30% deposit with the balance before shipping or at FOB, net 30/60/90, 100% prepay or CIA, and balance 30 days after arrival; terms it can't read are flagged and placed in full at the ship date. Returns one row per installment (supplier, PO, deposit/balance/net, due date, amount, paid, still due, and whether it is past its due date or upcoming), the total due per supplier by week or month, the amount due in the next 30 days and the largest week. Do not use for deciding what to reorder, drafting a purchase order, or checking a supplier invoice against a PO. This is not accounting or tax advice, and it does not pay or contact anyone. Read-only; it only calculates from the data provided and stores nothing.

plan_supplier_payments

Use this when an accountant, bookkeeper or controller asks why the inventory value in the inventory or ops system doesn't match the Inventory asset balance in QuickBooks, Xero or another general ledger, or needs an inventory reconciliation schedule for month-end or year-end. Do not use to compare counted quantities with system quantities, or a 3PL's stock with the seller's records. Needs the ops system's inventory value (a total or a per-SKU valuation file) and the GL Inventory balance (a number or a GL detail by item). Reconciling items can be given as amounts or as one CSV with a type and amount per line: received not billed, billed not received, in transit, adjustments or write-offs not posted, landed cost not capitalized; plus COGS from the GL and from the ops system for the period. Returns a schedule with each item's direction and impact, the unexplained residual and the share of the gap explained, and with per-SKU files a by-SKU view of which items drive the difference. Suggested entries are typical treatment only, not accounting advice. Read-only; stores nothing.

reconcile_inventory

Use this when a seller asks for SKU codes for their products or variants, wants a SKU naming system, or wants to fix messy and duplicate SKUs. Takes a product list (CSV or rows) with attribute columns such as brand, product or style, color, size and material, or just product names, and builds a consistent, readable code for each, like BRD-TSH-BLK-L. Sizes and common colors use standard codes, other words are abbreviated to a fixed segment length, and every code is unique: repeats and clashes with an optional list of existing SKUs get a numeric suffix. Returns each product with its suggested SKU and whether it was new, a resolved collision or a duplicate input. Read-only: it computes suggested codes and returns them in the conversation for the user to copy. It does not create, save or change any SKU, product or listing in any store, marketplace or system, and it stores nothing.

generate_skus

Use this when someone pastes or uploads raw X12 EDI and asks what it says, what an 850, 856 or 810 means, why a retailer rejected a document, or whether the counts and totals in an EDI file add up. Supports 850 purchase orders, 855 PO acknowledgments, 856 advance ship notices (with the shipment/order/pack/item hierarchy and SSCC carton labels), 810 invoices, 846 inventory advice, 860 PO changes, 940/945 warehouse orders and advice, and 997 functional acknowledgments; other sets are listed segment by segment. Reads the separators from the ISA header, returns the line items (item IDs, quantities, prices, totals) and flags structural errors: SE segment counts, control number mismatches, GE/IEA counts, CTT line counts, invoice totals that don't match the lines, and missing required segments. view=segments explains every segment and element in plain English instead. It checks X12 structure, not a specific retailer's implementation guide. Read-only; stores nothing.

translate_edi