Een print-on-demand verkoper opent in februari zijn Shopify Payments 1099-K en ziet een getal dat op niets lijkt wat hij daadwerkelijk heeft verdiend. Het formulier vermeldt $50.000 aan bruto betalingen. Zijn bankrekening groeide dat jaar met ongeveer $14.000. Er is niets mis — maar als hij die $50.000 als inkomen opgeeft zonder te begrijpen waar de overige $36.000 is gebleven, betaalt hij ofwel fors te veel belasting aan de IRS, ofwel raakt hij in paniek dat er iets is gestolen.
Dat gat is de meest voorkomende boekhoudfout die print-on-demand (POD) verkopers maken, en het komt voort uit een detail dat bijna niemand duidelijk uitlegt: het platform waarop je verkoopt bepaalt welke belastingen je verschuldigd bent en hoe je je kosten mag verantwoorden. Als je dat onderscheid verkeerd interpreteert, gaat alles daarna — je COGS, je sales tax-aangiftes, je Schedule C — op manieren mis die achteraf moeilijk te herstellen zijn.
Twee bedrijfsmodellen, twee compleet verschillende belastingplaatjes
Print-on-demand omvat een breed scala aan opzetten, maar voor boekhoudkundige doeleinden zijn er eigenlijk maar twee modellen, en die gedragen zich totaal anders.
Model A: jij bent de merchant of record. Je runt je eigen webshop — Shopify, WooCommerce, of een zelf-gehoste Etsy-shop — en koppelt een fulfillmentpartner zoals Printful of Printify via een integratie. De klant betaalt jou rechtstreeks. Jij betaalt vervolgens het fulfillmentbedrijf een basisproductiekost per artikel. Juridisch ben jij de verkoper, wat betekent dat jij de sales tax-verplichting draagt en dat je de werkelijke kostprijs van de verkochte goederen (COGS) mag aftrekken.
Model B: jij bent een royaltyontvanger. Je uploadt ontwerpen naar een marketplace zoals Redbubble, Merch by Amazon, TeePublic, Society6, Zazzle of Spring. De marketplace bepaalt de prijs van het product, verwerkt de transactie, produceert en verzendt het, en betaalt jou een royalty per verkoop. Je hebt nooit met een sales tax-aangifte te maken, en — dit is het deel dat verkopers vaak fout hebben — je hebt geen aftrekbare COGS, omdat je nooit voor de goederen hebt betaald. Je hele "productkosten" zitten al verwerkt in het aandeel van de marketplace voordat je de royalty ooit ziet.
Deze twee modellen door elkaar halen is waar de meeste POD-boekhoudfouten beginnen. Een verkoper die ervan uitgaat dat zijn Redbubble-royaltyinkomen op dezelfde manier werkt als zijn Shopify-winkelomzet, zal ofwel een COGS-aftrek verzinnen waar hij geen recht op heeft, ofwel nalaten zich te registreren voor sales tax-vergunningen die hij daadwerkelijk nodig heeft.
Hoe COGS in de praktijk werkt voor verkopers met Model A
Als je je eigen webshop runt via Printful of Printify, is de vergoeding die je betaalt voor het blanco product, het printen en het inpakken een legitieme kostprijs van de verkochte goederen — maar die moet wel op de juiste plek in je boekhouding terechtkomen.
Op Schedule C betekent dat:
- De basisproductiekost komt op Part III, Line 36 (aankopen/inkopen).
- Verzendkosten die de fulfillmentpartner in rekening brengt, horen doorgaans thuis op Part III, Line 38 (overige kosten) of worden bij de COGS gevoegd, afhankelijk van hoe je boekhoudsoftware dit categoriseert — het gaat om consistentie, niet om de exacte regel.
- De eindvoorraad is $0. Print-on-demand is per definitie made-to-order. Je houdt nooit fysieke voorraad aan, dus is er aan het einde van het jaar geen voorraadwaarderingsstap zoals een traditionele retailer die moet doorlopen.
De praktische fout om op te letten: veel verkopers registreren de omzet van een verkoop zodra Shopify Payments deze stort, maar vergeten de fulfillmentfactuur die Printful of Printify enkele dagen later in rekening brengt apart vast te leggen — vaak in een andere batch en soms zelfs in een andere maand. Als je boekhouding alleen de stortingskant vastlegt, oogt je winst-en-verliesrekening kunstmatig winstgevend totdat de fulfillmentfactuur wordt bijgewerkt — en tegen de tijd dat je het merkt, heb je mogelijk al een kwartaal aan voorlopige belasting aangegeven op basis van het opgeblazen cijfer.
De oplossing is mechanisch maar essentieel: stem elke uitbetaling af tegen de bijbehorende fulfillmentfactuur voordat je de boeken voor die periode afsluit, niet erna.
Multi-platform sales tax: waarom "nexus" op elk kanaal iets anders betekent
Dit is het onderdeel waar verkopers over struikelen die dezelfde ontwerpen via meerdere kanalen verkopen — bijvoorbeeld een Shopify-winkel en een Etsy-shop en een Redbubble-account.
Marketplaces (Model B) zijn marketplace facilitators. Etsy, Redbubble, Amazon Merch en vergelijkbare platforms zijn wettelijk verplicht om namens jou sales tax te berekenen, te innen en af te dragen in elke staat waar dat vereist is. Jij registreert je niet, je doet geen aangifte, je raakt het niet aan.
Je eigen webshop (Model A) is niet automatisch gedekt. Shopify zelf is geen marketplace facilitator voor bestellingen die via je eigen domein worden geplaatst — die verantwoordelijkheid draag je zelf, staat voor staat, op basis van waar je economische nexusdrempels hebt overschreden. (Shopify's aparte "Shop"-appkanaal is sinds 2025 begonnen met het innen en afdragen van belasting op in aanmerking komende bestellingen, maar dat geldt alleen voor verkopen via dat specifieke kanaal — niet voor je primaire webshop.)
Dat betekent dat een en dezelfde verkoper legitiem sales tax-registratie en -aangiftes verschuldigd kan zijn in één staat via zijn Shopify-winkel, terwijl hij helemaal niets verschuldigd is over hetzelfde product verkocht via Etsy of Redbubble in diezelfde staat. Je boekhouding moet bijhouden welk kanaal elke verkoop heeft gegenereerd, niet alleen de totale omzet, anders registreer je je voor vergunningen die je niet nodig had of — erger nog — mis je vergunningen die je wel nodig had.
Er is een tweede laag die specifiek is voor POD: de fulfillmentkosten zelf kunnen belastbaar zijn. Als je geen resale certificate indient bij Printful of Printify, brengen zij je sales tax in rekening over de groothandelsproductiekost — belasting die je vervolgens niet legaal kunt terugvorderen, omdat jij niet de eindconsument bent. Het indienen van een resale certificate (via de belastinginstellingen van het platform, met een staatspecifiek certificaat of het uniforme formulier van de Multistate Tax Commission, dat in de meeste staten wordt geaccepteerd) voorkomt die dubbele belasting en is het waard om te doen vóór je eerste verkoop, niet nadat je een onverklaarbare kostenpost op een factuur opmerkt.
Uitbetalingen afstemmen op fulfillmentfacturen zonder er gek van te worden
De kernuitdaging in de operationele kant van POD-boekhouding is geen ingewikkelde wiskunde — het zijn timingverschillen tussen systemen die nooit zijn ontworpen om netjes met elkaar te communiceren:
- Een klant betaalt Shopify of Etsy. Die betaling wordt verwerkt via Shopify Payments, Stripe of Etsy Payments volgens zijn eigen schema (vaak 2-5 werkdagen later, gebundeld met andere bestellingen).
- De bestelling wordt doorgestuurd naar Printful of Printify, dat je apart factureert — soms per bestelling, soms gebundeld — vaak volgens een ander schema dan de uitbetaling.
- Als je op meerdere kanalen verkoopt, produceert elk kanaal zijn eigen uitbetalingsrapport, zijn eigen kostenstructuur en zijn eigen timing, allemaal terugverwijzend naar dezelfde fulfillmentpartner.
Zonder een bewust proces is het gemakkelijk om de uitbetaling als omzet te registreren en nooit na te gaan of de bijbehorende fulfillmentkost daadwerkelijk is geboekt. Eén simpele gewoonte lost het grootste deel hiervan op: haal voordat je een maand afsluit het orderniveau-kostenrapport van de fulfillmentpartner op en vergelijk het regel voor regel met de kanaaluitbetalingsrapporten voor diezelfde periode. Alles wat niet overeenkomt — een bestelling die een klantbetaling toont maar geen bijbehorende fulfillmentkost, of andersom — is ofwel een timingverschil dat zich in de volgende periode oplost, ofwel een echte fout die het nu waard is om te onderzoeken.
Dit is precies het soort afstemming dat baat heeft bij gegevens die je daadwerkelijk kunt controleren in plaats van een black-box dashboard. Wanneer je fulfillmentfacturen, kanaaluitbetalingen en geïnde sales tax allemaal als platte-tekst transacties worden vastgelegd met duidelijke verwijzingen terug naar de brononderneming, kost het traceren van een discrepantie minuten in plaats van een middag CSV's exporteren uit drie verschillende platforms.
En de 1099's?
Omdat verkopers met Model A merchant of record zijn, geven Printful en Printify je helemaal geen 1099 — je 1099-K, als je die al ontvangt, komt van je betalingsverwerker (Shopify Payments, PayPal, Stripe) op basis van het bruto transactievolume, niet het netto-inkomen. Dat is het getal dat de hierboven uitgelegde COGS-aftrek nodig heeft om een nauwkeurig winstcijfer te worden.
Marketplaces met Model B verschillen onderling: Amazon Merch en Zazzle geven direct 1099's uit voor royaltyinkomen boven de rapportagedrempel; andere, waaronder Redbubble, TeePublic en Society6, laten uitbetalingen via PayPal of Payoneer lopen, die in plaats daarvan de 1099-K uitgeven als de drempel wordt gehaald. Hoe dan ook: de rapportagedrempel bepaalt alleen of het platform je een formulier moet sturen — het heeft geen invloed op of het inkomen belastbaar is. Elke dollar aan royalty- of webshopwinst is aangifteplichtig, of er nu wel of niet een 1099 in je inbox verschijnt.
Nog een classificatiedetail dat het waard is om te vermelden: hoewel marketplaces Model B-betalingen vaak "royalty's" noemen, behandelt de IRS inkomen uit een doorlopende handel of bedrijf als zelfstandigeninkomen dat onderworpen is aan self-employment tax — niet als passief royaltyinkomen — als je actief ontwerpen uploadt en de shop runt als een bedrijf in plaats van een eenmalig stuk intellectueel eigendom te licentiëren.
Houd je print-on-demand boekhouding structureel op orde
Of je nu één Shopify-webshop runt via Printful of vijf marketplaces tegelijk jongleert, de verkopers die verrassingen aan het einde van het jaar vermijden zijn degenen die fulfillmentkosten elke maand tegen uitbetalingen afstemmen in plaats van elk jaar in april. Beancount.io geeft je platte-tekst, versiebeheerde boekhouding waarmee het eenvoudig wordt om COGS, geïnde sales tax en multichannel-uitbetalingen bij te houden als duidelijk gelabelde, controleerbare transacties — geen vendor lock-in, geen black box. Ga gratis aan de slag en ontdek waarom developers en financieel onderlegde verkopers overstappen op platte-tekst boekhouding.
