Trust a scheduled cost-of-goods import only after you have checked what the source contains, where each field goes, and whether the resulting cost change explains the movement in profit. A completed daily sync can carry the wrong cost just as consistently as the right one.
For an Amazon seller, the practical test is whether the correct product, marketplace, sellable unit and cost period or batch reached the reporting system. Then a before-and-after comparison should account for the change in reported COGS. Those checks give you a basis for using the updated margin in pricing, advertising and replenishment decisions.
This workflow focuses on operating a recurring import. It assumes you have already chosen a costing method and agreed what belongs in your unit cost. The checks are recommended controls you can maintain in a working spreadsheet; they are not claims that an import tool automatically performs an audit.
What does a scheduled COGS import actually do?
In sellerboard, Settings → Automation → COGS import accepts a Google Sheets link or a direct CSV/Excel URL. You choose a daily sync time, map columns such as ASIN, SKU, batch quantity, period start date and cost, and select Weighted, By period or FIFO. The automatic COGS import release guide describes a daily read that applies changes from the source.
That removes a recurring transfer task. It does not establish whether a supplier invoice was entered correctly, whether a newly launched SKU reached the source, or whether a cost represents one item or a multipack. Those questions need evidence outside the transfer itself.
Treat the workflow as three connected records: the invoice or other original cost evidence, the import-ready file, and the resulting product cost and profit report. If a number is wrong, knowing which connection failed makes correction much faster than repeatedly uploading the same file.
How do you know the source file is complete?
Start with a list of products and cost records that the source is supposed to cover. Define whether a row represents a product’s current cost, a dated cost period, or an inventory batch. Record the intended marketplaces and currencies. A file of current costs and a file of all historical batches answer different questions, even when they share the same column names.
Compare that scope with the file actually available at the import URL. Check the exact workbook, sheet or export, including its header row and last data row. A colleague’s working spreadsheet may contain the new batch while the published export still ends at last month’s data.
Use counts that match the row definition. For a batch file, 120 rows need not mean 120 products: one product may have several legitimate batches. Count distinct product-marketplace combinations separately from batch rows. Compare both with the expected population and review the differences by identifier.
A practical source summary might contain these controls:
| Control | What to compare | What an exception means |
|---|---|---|
| Expected products | Approved product list versus distinct source identifiers | Missing, unexpected or wrongly mapped product |
| Expected cost records | Approved periods or batches versus source rows | Omitted history, duplicate batch or wrong scope |
| Batch units | Source quantities versus receiving records | Units, cartons or ordered quantity may be confused |
| Extended batch cost | Quantity × unit cost, by currency | Possible allocation, decimal or quantity error |
| Source freshness | Latest approved change versus exported file | Upstream update may not have reached the import |
Do not combine USD and EUR totals to make a single control number. Do not use a row count alone as proof of completeness. A deleted row and an accidental duplicate can leave the count unchanged.
Keep an exception list for products whose costs are legitimately unresolved. A blank cost, a confirmed zero cost and a missing product are different cases. Write down the reason and who will resolve it rather than replacing all three with zero to make the file pass a superficial check.
Which mappings deserve the closest attention?
Mapping is a definition exercise before it is a click in a dialog. Write one plain-language sentence for each field: what it identifies, what units it uses and what event its date represents. Have the person maintaining the source and the person reading profit agree on those meanings.
Product identifiers need an exact cross-check. A supplier item number may differ from your Amazon SKU, and one parent listing can contain children with different costs. Preserve identifiers as text where necessary so spreadsheet formatting does not remove leading zeroes. Confirm that a source row reaches the intended product and marketplace, especially where the same identifier appears across countries.
Cost must use the agreed sellable unit. If a case of 12 costs $72, the merchandise cost is $6 per single item. If the listing sells a two-pack, its merchandise cost is $12 before any additional allocated costs. Importing $72, $6 or $12 into the wrong listing creates a different error; each is a valid number in the wrong context.
Quantity needs the same care. A batch of 50 cartons containing 12 sellable units each represents 600 units, assuming the listing sells single items. Compare the quantity with the relevant receiving evidence. A supplier’s order quantity may include units that have not arrived or cannot be sold.
A date should represent the event required by the selected costing setup. A supplier’s invoice date, payment date, receipt date and period start are not interchangeable. Use the format expected by the import and test an unambiguous example; do not assume a date such as 03/04 will be interpreted the same way in every locale. Changing the daily run time cannot fix the wrong effective date inside a row.
Finally, check the cost definition. If inbound freight is included in the imported unit cost, identify how the same freight is represented elsewhere in the profit calculation. The control is to count each cost once under the intended treatment, not to add every available expense field together.
How should you test a mapping before relying on it?
Choose a small set of representative real records whose expected treatment you can calculate independently. Include a straightforward single-unit product, a multipack or bundle if you sell one, a recent cost change and a product with more than one period or batch. Add a marketplace-specific record where that risk exists. Include an unchanged record as a comparison.
For each, retain the original evidence, source row, expected destination and expected outcome. Check the mapped values and then the saved product cost. sellerboard’s Products documentation explains how to inspect costs by batch, period and marketplace through the COGS editor. Review the actual record there rather than relying only on the estimated profit-per-unit display.
Test boundaries as well as ordinary rows. For a period-based setup, inspect a sale before and after the intended change. For a batch-based setup, check the quantity and applicable batch sequence. Keep the selected accounting method fixed while testing the import, so a method change does not obscure a mapping problem.
A sample verifies the cases you checked. It does not establish that every record is correct. Run whole-file checks for missing identifiers, unexpected duplicates, invalid values and coverage gaps alongside the sample review. Treat any unusual zero or negative value as something to investigate against the source evidence, rather than assuming it is always invalid or automatically acceptable.
Do not test deletion or blank-value behavior on live history just to see what happens. The effect of omitting a row, clearing a cell or reusing a batch identifier needs current documentation or a controlled test with known consequences. A description of manual upload behavior does not automatically establish the behavior of a scheduled import.
What should you save before the next run?
Retain a copy of the exact import-ready source, its generation time, the source owner and a short description of approved changes. Save the mapping and selected method in a reviewable form. Keep this evidence somewhere your team can retrieve without depending on the latest editable sheet remaining unchanged.
Also capture a baseline report for the affected products and a fixed reporting period. Record marketplace, currency, filters and relevant calculation settings. Prefer a completed period with stable sales data when checking a correction; very recent periods can change for reasons unrelated to COGS.
Schedule the import after the upstream file is ready, allowing for the normal export delay. Check the timezone shown in the actual scheduling interface. If the source refreshes during the import window, arrange a stable approved export so the run does not depend on a file being edited midway through preparation.
ICAEW’s principles for good spreadsheet practice support clear inputs and outputs, testing, review and version control. Applied here, the useful record is the source version and expected result for a particular run. Keeping a source snapshot does not create a built-in rollback function in the receiving application.
How do you reconcile COGS before and after a run?
Compare the same reporting period, products, marketplace and currency before and after the source change is applied. Confirm that the expected values reached the product records. Then explain the movement in the COGS line separately from movements in sales, fees, refunds or other expenses.
For a simple period-based correction affecting otherwise unchanged sales:
Expected COGS change = affected sold units × (new unit cost − previous unit cost)
Sum the result across the affected products. For FIFO or weighted calculations, reconstruct the applicable batch consumption or weighted cost instead of multiplying every sale by the newest purchase price. If units or other inputs changed between snapshots, identify those changes separately.
Here is a hypothetical check of three products. All sales fall inside the corrected cost periods, quantities are unchanged, and there are no returns or mixed-batch complications. Dollar amounts are illustrative.
| Product | Sold units | Old → new unit cost | Expected COGS change |
|---|---|---|---|
| SKU A | 400 | $8.00 → $8.50 | +$200 |
| SKU B | 100 | $12.00 → $12.30 | +$30 |
| SKU C | 250 | $4.00 → $3.80 | −$50 |
| Total | 750 | Mixed costs | +$180 |
Before the update, COGS is (400 × $8) + (100 × $12) + (250 × $4) = $5,400. Afterward, it should be $3,400 + $1,230 + $950 = $5,580. With everything else unchanged, profit should fall by $180.
Suppose the baseline profit was $4,100. The expected result is $3,920, but the refreshed report shows $3,910. The remaining $10 decrease needs an explanation. If the COGS line increased by the expected $180 and a newly posted fee added $10, the bridge reconciles. If COGS itself increased by $190, investigate the cost records and affected quantities instead.
This is why checking only total profit is weak. A new sale can conceal an overstated cost; a late fee can make a correct import look wrong. sellerboard’s Reports guide describes exports for product-level analysis. Align columns by their labels and keep the same report settings when comparing snapshots.
Also separate inventory value from expense on sold units. A new 500-unit batch at $8.50 has a value of $4,250, but that does not mean $4,250 should immediately appear as COGS for the selected sales period. The import can change available inventory costs without every unit being sold.
What should happen when the checks disagree?
Keep the affected profit figure provisional while you locate the discrepancy. Identify whether the fault is in the original cost evidence, source preparation, mapping, application to a product, or the comparison report. Record the affected products and periods so the issue does not become an account-wide mystery.
Correct the authoritative source and verify the corresponding destination records. If a bad file could be consumed again, prevent its next release or use a confirmed scheduling control to stop repetition while the issue is investigated. Do not leave an incorrect source in place after manually correcting only the destination.
Avoid assuming that re-importing an older file will undo the change. Before rerunning, establish how the import identifies existing records and handles amendments. Ask support about the specific record type and intended correction when that behavior is unclear. Preserve the before-and-after evidence rather than experimenting repeatedly on financial history.
After correction, repeat both the representative-record checks and the COGS bridge. Close the exception only when the numbers agree or the remaining difference has a documented cause, owner and next action. A note saying “uploaded again” is a record of activity, not evidence that the affected margin is usable.
Which recurring checks are worth keeping?
Use a short run log with the source version, expected changes, records reviewed, observed COGS movement, unresolved differences and reviewer. Set review frequency around the risk: a changed file layout, new marketplace, first multipack or large cost revision deserves closer attention than an unchanged routine source.
Agree a monetary investigation threshold for small reconciliation differences, but keep identity, currency and missing-product checks separate. An apparently small error can be systematic and grow with sales. A threshold should help prioritize review, not make a mismatched SKU acceptable.
Recheck after someone inserts or renames columns, changes the export process, adds formulas or changes who owns the source. Keep one clear route for approved cost updates. Parallel manual edits and scheduled imports need an explicit ownership rule, or each person may believe someone else’s figure is authoritative.
What mistakes make automated imports unreliable?
- Using “the file opened” as proof that it contains every required product or batch
- Mapping supplier units to sellable units without checking packs and cartons
- Treating an invoice date as the correct effective date without checking its meaning
- Comparing today’s live profit with yesterday’s different period or filters
- Expecting total purchase value to become COGS immediately
- Fixing the destination while leaving the recurring source wrong
- Assuming a saved source copy guarantees an automatic rollback
What do sellers ask about scheduled COGS checks?
Does a successful scheduled run prove that my profit is accurate?
No. It establishes less than the full chain of evidence. Verify source coverage, mapping and the resulting cost records, then reconcile the report movement.
How many sample rows should I check?
Choose records covering your actual risks and costing structures. There is no universal sample size that guarantees accuracy. Combine representative checks with whole-file coverage and value checks.
Should every daily run change my profit?
No. An unchanged source may need no update, and a changed cost may apply outside the reporting period you selected. Start with the expected effect rather than assuming movement is required.
Can I remove an old batch from the source after it sells out?
Confirm the scheduled import’s treatment of omitted records before changing the source scope. Keep the evidence needed to explain historical costs; do not assume omission is either harmless or a deletion command.
What is the minimum evidence to keep?
Keep the approved source version, mapping, reporting scope, expected changes and reconciled outcome, with a record of unresolved exceptions. Store original invoices or receiving evidence through your normal recordkeeping process.
A reliable scheduled import leaves you able to explain the next profit update. When the source population, mapped records and COGS movement agree, the automation has earned a place in your decision process. When they do not, the checks tell you what to resolve before acting on the margin.
