What is COGS in DataDoe?

Cost of goods sold (COGS) is what you pay to source or make one unit of a product. DataDoe does not fetch COGS from Amazon. You upload it as a CSV file. Uploaded COGS is used in profit reports and tables such as Order Line Items and Profit by SKU and Date.

Where do I upload COGS?

1. Open Sellers & Vendors (opens in a new tab).
2. Select a Seller or Vendor. On a dual account, select the side whose costs you want to manage.
3. Open COGS for a Seller or Your uploaded product cost for a Vendor. Vendors use the DataDoe CSV format.

You can also manage COGS manually for each SKU in the Inventory report (opens in a new tab).

Your uploaded product cost for vendors

Upload the cost you pay to manufacture or acquire one unit of each reported ASIN. You can use an ASIN default or keep separate dated costs by vendor code, fulfillment method and exact purchase order. Use the template on the upload page. Review and edit saved ASIN costs below the form.

Vendor CSV files use child_asin, from, cost_item_value, optional cost_item_shipping_value, cost_currency and item_supplier_name. You can supply sku when it resolves uniquely to an ASIN in the selected Vendor account. When both identifiers are present, they must agree. Optional vendor_code, fulfillment_method and purchase_order_number identify a separate cost history. Item cost is required. Zero is valid, but a blank cost is rejected. Shipping defaults to zero. Currency defaults to the selected marketplace currency, and other currencies are rejected. Costs are per single ASIN unit. Enter an average landed cost if you maintain one, and avoid adding freight or tariffs again as shipping when they are already included. Costs stay per single item. Confirm pack and invoice quantity conversions separately in the mapping editor; DataDoe does not infer them or convert currencies.

The latest from date on or before the report date applies until the next dated row. An empty from uses the earliest date. Re-uploading the same Vendor, marketplace, ASIN, vendor code, fulfillment method, exact PO and date updates that row. Conflicting costs for that full key are rejected. Future rows do not change earlier days. A backdated correction intentionally changes historical estimates.

Your uploaded product cost does not change Amazon's purchase price. Amazon-reported costs include shipped COGS, Amazon's procurement cost for customer shipments, and contra-COGS. Shipped revenue is Amazon's consumer retail revenue. Net PPM is Amazon's margin. These metrics stay separate from your uploads.

Vendor cost tables and coverage

Vendor Listings shows the ASIN default cost effective today in uploaded_cogs_unit_item_value, uploaded_cogs_unit_shipping_value, uploaded_cogs_unit_total_value, uploaded_cogs_currency, uploaded_cogs_effective_from and uploaded_cogs_present. The old cogs_* listing fields remain compatibility aliases. New integrations use the explicit names. The amazon_cogs ledger contains the dated user-maintained rows, with an empty SKU for Vendor costs.

Sales, Traffic & Inventory by ASIN & Date adds those unit fields and estimated Sourcing / Retail cost totals. The catalog-day, ASIN-week, catalog-week, ASIN-month and catalog-month tables add only totals and coverage, not a single unit cost for the period. Their uploaded_cogs_sourcing_retail_*total_value fields sum each day's shipped units times that day's applicable unit cost. Native Amazon period metrics stay unchanged.

Use totals only when uploaded_cogs_sourcing_retail_complete is true. Missing daily history, missing costs, currency differences or a mismatch with native Amazon shipment totals makes the estimate incomplete and its complete-period totals empty. Coverage unit counts describe only observed daily data. uploaded_cogs_present distinguishes an explicit zero from a missing cost. Manufacturing and Sourcing overlap. Do not add them together or substitute Manufacturing when Sourcing is missing.

Transaction costs and margins

Use the mapping editor on Your uploaded product cost to confirm fulfillment methods, units per case and invoice units per quantity. A rule can apply to an ASIN, vendor code and exact PO. Regular and Rush orders do not identify Direct Import or Global Direct Import. Unknown or conflicting mappings leave affected margins unavailable. Saved mappings reach margins after the next scheduled account configuration sync and warehouse refresh. Saving does not refresh the margin tables immediately.

For each transaction, an exact PO cost takes priority, followed by the most specific vendor-code and fulfillment match, then the explicit ASIN default. Equally specific matches are unresolved. Missing transaction identifiers do not silently select a broader cost.

The transaction tables show three separate views:

• PO margins project tax-exclusive wholesale revenue less uploaded costs using the PO date. Regular and Direct Fulfillment orders stay separate. Cancelled orders have no active margin.
• Invoice settlements use the invoice issue-date cost and reconcile the complete payment history. Partial payments have no final settlement margin. Reopening an invoice recalculates its current state.
• Payment margins show cash on the payment date and settled-invoice margins separately. An invoice's full cost is counted once at final settlement. It is never divided across installments. Net receipts already include signed deductions; do not subtract them again.

Deductions linked by invoice number or purchase order leave that invoice's settled margin unavailable until resolved. Other deductions remain visible at payment level and do not block individual invoice margins.

Select a date range, inspect source details and export the full matching rows as CSV. A preview contains at most 500 rows. Use the coverage and missing-reason fields before summing margins. Missing identity, unit conversion, currency, tax or history reconciliation leaves the complete margin empty. These views measure product margins, not complete net profit.

A simple Sourcing / Retail margin estimate

For one Vendor, marketplace, date range and currency, sum the daily uploaded product-cost totals. Subtract this estimated own product cost from Amazon's reported Sourcing / Retail shipped COGS. If existing ad spend can be matched to the same scope, subtract it once. Otherwise, report margin before ads and explain why ads were excluded.

For example, Amazon shipped COGS of $800 and 10 shipped units at your uploaded unit cost of $70, with $0 shipping, give an estimated own product cost of $700. Estimated margin before ads is $100. Subtracting matched ad spend of $20 gives $80, or 10% of shipped COGS. These are illustrative figures.

Divide the estimated margin by shipped COGS only when shipped COGS is positive. Missing costs or source metrics make the estimate unavailable. Do not use retail revenue or today's listing price as a substitute. Do not subtract returns again or add estimated fees or contra-COGS. This sell-through estimate excludes batch accounting, PO receipts, invoices, cash timing, returns, charges, taxes and automatic FX. It is not a full vendor profit and loss.

Through the API and MCP, set accountType to VENDOR for Vendor Central, especially on dual accounts. Use cogs_upsert or POST /api/v1/cogs with an ASIN or a uniquely matching Vendor SKU. Optional vendorCode, fulfillmentMethod and purchaseOrderNumber select a separate dated cost history. Delete targets that full variant; leaving the variant fields empty selects the ASIN default. cogs_delete and DELETE /api/v1/cogs accept the same scope selection. Seller defaults and keys stay unchanged. Missing-cost notification emails and cogs_missing_list remain seller features.

How does effective dating work?

COGS is stored per SKU and From date. A row applies from that date until the next From date for the same SKU.

For example, SKU ABC-123 has a row with From date 2026-01-01. DataDoe uses that row for the SKU until you add another row with a later From date, such as 2026-03-01.

What is the file format?

Use the DataDoe CSV format to set costs per SKU and the date they start. You can download a sample CSV (opens in a new tab).

All required column headers must be present. You can omit optional columns from the header.

SellerBoard CSV format

You can upload a product CSV exported from SellerBoard without converting it to the DataDoe format. DataDoe reads these SellerBoard columns:

The upload uses the currency and marketplace selected in DataDoe. SellerBoard fields not listed above, including VAT, are ignored. DataDoe does not add or remove VAT from the uploaded cost. Make sure the Cost values in the file already represent the per-unit costs you want DataDoe to use.

For how DataDoe P&L compares to Sellerboard (no VAT row, different COGS engine, agent prompt), see Migrating from SellerBoard.

Re-uploading COGS

When you upload a COGS CSV, DataDoe matches each row on:

• SKU

• ASIN (child_asin)

• Currency (cost_currency)

• From date (from)

• Matching row → values are overwritten with what is in the file.

• No match → a new row is added (for example, a new effective date).

Re-uploading the same file with the same keys updates existing data. It does not create duplicate rows for the same SKU and From date.

Supplier name behaviour:

• If your CSV includes the item_supplier_name column, supplier values in the file replace stored values for matching rows. Leave a cell empty to clear the supplier name for that row.
• If your CSV does not include the item_supplier_name column, existing supplier names are preserved for matching rows.
• SellerBoard uploads never change supplier names on matching rows. New rows inserted from SellerBoard files have no supplier name.

Edits made in the per-SKU COGS editor also preserve supplier names when you change costs only.

Which tables use uploaded COGS?

Look for tables that contain COGS-related columns in the Data Scheme.

These tables include cogs_present. For a detailed row, true means an uploaded COGS record applies, even if its cost is zero. For a profit summary, true means every contributing shipped item and return has COGS. For an ad profit row, it means reported sales match the same- and other-SKU split and each positive part has a COGS estimate. false means coverage is incomplete. null means there are no relevant items, no positive ad sales, or the campaign type does not support COGS estimates.

How does DataDoe find missing COGS?

DataDoe checks each sale a seller made in the last 30 days against the COGS you uploaded, the same way profit tables do: a sale has COGS when a row matches its SKU and ASIN and the row's From date is on or before the sale date. Profit counts the cost of a sale without COGS as 0, so profit is overstated until you add it.

• Upload COGS page: a warning shows how many SKUs sold in the last 30 days are missing COGS and how many units those sales account for. Select Download CSV to get the list with SKU, ASIN, product name, units without COGS, last sale date without COGS, and reason. Add the costs and upload them.
• Email: every 5 days, DataDoe checks each seller that has at least one COGS row. When SKUs are missing, organization owners get one summary email for all sellers and vendors. Owners can turn it off in Settings → Account → E-Mail Notifications (Missing COGS or vendor codes).
• AI agents and apps: the MCP tool cogs_missing_list and the API endpoint GET /api/v1/cogs/missing return the same list. Export source responses include catalogCoverageNotice when the latest check found missing COGS.

A SKU is listed with one of these reasons:

Cancelled orders are ignored. Orders that Amazon has not assigned an ASIN to yet are matched by SKU only.

Need help?

If you have questions about uploading COGS or your data, contact us (opens in a new tab).