Costs as of the sale, corrected without rewriting history.

Shopify keeps one unit cost per variant and no history. Offer Suite keeps the cost of goods beside every cost Shopify has no field for (3PL fees, labels, inserts, packaging, freight, payment processing), each under a kind with a grain. The grain stops a cost being counted twice: a per-parcel kind on a three-pack is counted once, a per-unit kind three times.

Until you add your own amount for a kind, the profile's default applies, in forecast and realized profit alike. Freight and shipping boxes have no estimate yet: they count only once your agent posts an order's actual cost.

A cost is a row with an amount and the date it takes effect, which can be in the past. Rows are appended, never edited: a correction is a new row for the same date, and the ledger keeps both, each with when it was recorded.

The dashboard's Costs page adds rows, voids them, imports a CSV and seeds from Shopify.

Every write that moves a past cost (a row, a void, a CSV import, a Shopify seed, a kind change or a variant re-mapped to another item) records a restatement and recosts the affected past orders in the current view. The as-recorded view keeps the costs each order was booked with. Every realized read in the API, MCP and Sidekick takes the view to use.

Each restatement reports what triggered it, its scope (the items, products, offers or kinds it touches, and the date it reaches back to), how many orders it recosts, its status and the change in the workspace's realized profit since that date. The change is one figure for the whole job, not a breakdown per order.

A restatement that fails stays listed with its error and can be run again. The realized mirror is revisioned against the orders it copies, and a sweep every 5 minutes re-mirrors any order left behind and resends any restatement that was not sent.

• Costs attach to an item, the physical SKU, so one row covers every variant that maps to it. A variant can be re-pointed to another item through the API or MCP, and its past orders are restated.
• A kit is an item with a dated bill of materials, nesting up to 8 levels and refusing cycles. For a per-unit kind it has no row of its own for, a kit costs the sum of its components at the order's date; a recipe set from a date never recosts orders placed before that date.
• Shopify fixed-bundle orders are matched to a kit only on an exact match: the same parts, a whole multiple of one kit. Anything else counts as its parts, never a guess.
• GET /items/health runs eight checks, each listing its offenders, among them variants with no SKU, SKUs whose variants had different Shopify costs, reused SKUs, items or kit parts with no cost, unmapped order lines, orders missing a required cost kind and recent mapping changes.
• The same report gives the share of recent realized revenue on fully costed orders. The dashboard's Costs page shows that share and the uncosted items.

• One call seeds a cost-of-goods row per item from Shopify's unit costs, only where the amount changed, and can backdate them. Variants with no cost are skipped, not zeroed. When variants sharing a SKU carry different costs, nothing is written for that item and the conflict is reported, never guessed.
• Shopify overwrites unit costs and keeps no history, so each change it reports (a unit cost, a SKU, a new unmapped variant) becomes a dated proposal in an inbox you accept or ignore through the API, MCP or the dashboard's Costs page. Accepting appends a ledger row and restates.
• Auto-accept takes plain unit-cost changes only: never a cleared cost, a cost that conflicts with another variant of the item, or a SKU or new-variant proposal.

Your agent, or a script relaying your 3PL's or carrier's invoices, posts each order's actual shipping and fulfilment costs to POST /orders/actual-costs (the MCP tool record_actual_costs), up to 500 rows a call. Each actual replaces that kind's estimate in realized profit, in both views.

• Rows are append-only and idempotent by sourceRef: a credit is a negative row under its own reference, and a conflicting resend is refused.
• Per-parcel kinds are charged once per non-cancelled Shopify fulfilment, at least once per order.
• GET /orders/costs (get_order_costs) returns one order's estimate, actual and variance by kind, as the API computes them.

The actual-fee read has not yet run on a live Shopify Payments order.

Payment processing is a cost in both forecast and realized profit. The estimate is 2.9% of revenue as charged (lines after discounts, plus shipping, before tax) plus $0.30 per order, and either amount can be changed through the costs API.

On Shopify Payments orders that arrive by webhook, Offer Suite reads the actual fee from Shopify for up to about 12 hours; once it is known, it replaces the estimate on that order in realized profit. Other gateways, imported orders and orders whose fee never appears keep the estimate, and the forecast always uses it.

Once an order is paid, a line that a post-purchase upsell or any other order edit adds is stored as its own line of the order. It is costed from the ledger at the order's date, counted in that order's offer and option contribution in both views, and its refunds net against it.

A quantity change to a line the order was placed with stays an uncosted adjustment, shown apart from contribution. Upsell profit is not yet reported apart from the front-end sale.

Set through the API (GET and PATCH /tenant) or the MCP tools get_tenant and update_tenant.

• No built-in 3PL or carrier connector: actual costs arrive from your agent or a script.
• The dashboard has no as-of view and no controls for a kind's order scope, percent base or unit-cost inclusions; those are API and MCP only.
• The dashboard's Shopify seed shows only counts, not the conflicts it refused, and the dashboard and App Home have no settings page.
• Variance between estimated and actual costs is shown per order, not summed across offers.