How Do You Record POD Costs for Tax Filing?
12 POD Business & Ecommerce
POD bookkeeping fails in one specific place: the cost of a single order is split across four systems and never joined back together. The print charge sits in a supplier invoice, the shipping label in a carrier account, the platform fee in a payout report, and the refund in a support tool. Filing season then asks for a margin figure that no single system holds. The fix is a per-order record built at the time of sale, not a spreadsheet assembled in April. This guide covers which buckets exist, how to record each one, and where a record that looks fine will still fail a review.
Key Takeaways
- Print cost, shipping and platform fees belong in different buckets and are reported differently.
- Cost of goods sold attaches to the item sold, not to the month the invoice arrived.
- Refunds and reships need their own line or the margin figure overstates itself.
- A per-order record is cheaper to keep than to reconstruct.
- Bookkeeping for POD has to survive a change of platform mid-year.
The Four Buckets Every POD Order Produces
An order generates four cost events, and each one lands on a different document. The print and product charge comes from the fulfilment partner. The shipping charge comes from the carrier account or is bundled into the same invoice. The marketplace or payment processor fee comes from the payout report. The refund or reship comes from a support decision made weeks later.
POD bookkeeping starts by deciding which of those four is a cost of goods and which is an operating expense. Print cost is a cost of goods because it attaches to the unit sold. Platform fees and payment processing are operating expenses. Shipping is the awkward one: outbound shipping charged to the buyer behaves differently from shipping you absorb on a reship.
| Cost event | Where it appears | How to record it |
|---|---|---|
| Print and blank cost | Fulfilment invoice or API charge | Cost of goods sold, per unit, at the order |
| Outbound shipping | Carrier account or bundled invoice | Separate line, matched to the order |
| Platform and payment fees | Payout report, net of fees | Operating expense by channel and month |
| Refund, reship, replacement | Support tool, not the invoice | Own line, tied to the original order |
Why Cost of Goods Sold Has to Attach to the Order
A fulfilment invoice for March may cover orders shipped in February and orders from a December promotion that were reprinted in January. Recording it as a March expense puts the cost in a month that earned none of the revenue.
The unit-level POD bookkeeping record fixes this. If every order carries its print cost at the time it is placed, the invoice becomes a control total rather than the source of truth. You reconcile the month's invoices against the sum of per-order costs, and any gap is a missing record rather than a mystery.
The same logic holds whether the unit is a cotton tee, a polyester performance piece or a printed blank: the cost is the print charge plus the garment, and fabric weight in gsm changes neither the record structure nor the filing treatment.
This matters more in POD than in wholesale because there is no inventory to value. A print-on-demand seller has almost nothing on a shelf, so the cost of goods is almost entirely the production charge on units already sold. Get that per-order attachment right and the rest of the filing follows.
Recording Platform Fees Without Double Counting
A marketplace payout is usually net: gross sales minus referral fee, minus payment processing, minus any shipping programme charge. If you record the net figure as revenue, the fees disappear from the books and the margin looks better than it is.
Record gross revenue and the fee lines separately, in the same way the channel comparison treats fees as a cost line rather than a deduction. That keeps the effective take rate visible month to month, which is also the number you need when comparing channels. The full fee components are published per platform, so the split can be reconstructed from the payout report rather than estimated.
Stripe or PayPal fees on an own store follow the same rule: gross in, fee out, net to the bank. One habit, applied consistently, prevents the two most common filing errors in a POD business.
Refunds, Reships and the Margin That Looks Too Good
A refund removes revenue and usually leaves the print cost behind. A reship adds a second print and a second label with no new revenue at all. Neither event appears on the original invoice, so a bookkeeping system built only on invoices will miss both.
Give reships and refunds their own line and tie each one to the original order number. Then the margin on that order, after the reship, is visible in the bookkeeping without a second calculation. Without a bookkeeping link from reship to original order, a seller can report a healthy gross margin while a fifth of the orders quietly lost money.
In our experience the reship line is the one that gets skipped, because the original order already recorded a cost and the second one feels like a duplicate. It is not a duplicate. It is a separate production event and it consumes cash.
How Long to Keep POD Bookkeeping Records
POD bookkeeping only needs four artifacts per period: the per-order record, the fulfilment invoice, the payout report and the refund decision. Plus the per-order table that joins them, and nothing else.
Retention periods differ by jurisdiction, and the bookkeeping rule you adopt should match the one your accountant already uses., so check your own tax authority's published guidance rather than copying a number from a blog. The practical point is that the per-order table is small and cheap to keep, while reconstructing it after a platform migration is expensive or impossible.
Where This POD Bookkeeping Approach Does Not Work
Bookkeeping that starts at the order survives a platform migration, while a spreadsheet rebuilt afterwards usually does not.
A per-order record is the wrong tool if you sell through a marketplace that reports your revenue for you and withholds tax. In that case the platform's report is the filing basis and your record is a check on it, not the source.
It is also limited when you resell through a wholesale arrangement where you never see the end-order cost. Then the cost of goods is the invoice to your reseller, and order-level detail does not exist.
And it does not remove the need for an accountant. The record makes the conversation short; it does not decide how your jurisdiction treats shipping income or a reship charge.
Frequently Asked Questions
Is print cost a cost of goods or an expense?
For a POD seller it is a cost of goods, because it attaches to a specific unit sold. Fees charged by the channel sit outside that bucket.
Should shipping be recorded with the product?
Separately. Outbound shipping has its own treatment in most jurisdictions, and a reship's shipping is a cost with no matching revenue.
How do I record a reship?
As its own cost line tied to the original order, with the reason recorded. Without the link the order looks profitable when it was not.
Do I need a per-order record if the platform reports my sales?
You need it as a control. The platform report is the filing basis, but it will not tell you which orders lost money after a reship.
The Short Version
The custom product catalogue gives the per-unit print charge that starts every record. POD bookkeeping is four buckets joined by one order number: print cost, shipping, platform fees, and refunds or reships. Attach each to the order at the time it happens, keep the invoice as a control total, and record gross revenue with fees broken out.
Do that and POD bookkeeping becomes a monthly reconciliation rather than an annual reconstruction. The margin figure you report is then the margin you earned, which is the only version worth filing.
Related Articles
CAC Payback Windows for Custom Product Brands
POD Profit Margin Benchmarks by Product Type
What Causes Wrong-Item Shipments in POD?
