Je Tecton-factuur noemt één bedrag, je AWS-rekening draagt stilletjes de rest, en geen van beide documenten noemt zichzelf de volledige kost van het serveren van features. Die splitsing is de valkuil. Tecton rekent op basis van verbruik — computekredieten voor de pipelines die het draait plus de cloudresources die die pipelines verbruiken binnen je eigen account — dus de factuur die je van Tecton ontvangt is altijd maar een deel van de uitgaven. Als je boekhouding de factuur vastlegt en daar stopt, is je kostprijs van verkochte goederen te laag, je brutomarge te hoog, en elke prijsbeslissing die je op die marge bouwt, rust op een getal dat nooit volledig was.
Dit artikel legt uit hoe Tecton daadwerkelijk meet en factureert, waarom productie-feature-serving thuishoort in de kostprijs van verkochte goederen, hoe je vooruitbetaalde kredieten en verbruiksverplichtingen behandelt, en hoe je dit alles aan het maandeinde afstemt zodat elke dollar op de juiste rekening landt.
Hoe Tecton Meet: Feature Views, Geen Seats
Tecton is een beheerd feature-platform voor machine learning. Je definieert transformaties over je data als feature views, Tecton berekent ze op batch- of streaming-pipelines, en het serveert de resultaten aan je modellen — een offline store voor grootschalige training-retrieval en een online store voor retrieval met lage latentie tijdens live inferentie. Er zijn geen licenties per seat om te tellen. Je betaalt voor wat het platform verbruikt tijdens het berekenen, opslaan en serveren van je features.
Dat verbruik valt in twee buckets die op twee verschillende plekken worden gefactureerd, en dat is het eerste dat je je moet eigen maken.
De eerste bucket is Tecton-kredieten. Deze dekken de compute die Tecton namens jou beheert: Spark streaming compute-kredieten voor stream feature views, Spark batch compute-kredieten voor batch feature views. Je gebruik van het platform vertaalt zich in kredieten, en de kredieten verschijnen op de Tecton-factuur.
De tweede bucket is de infrastructuur zelf, en die wordt gefactureerd via je eigen cloudaccount. Tecton beheert compute- en opslagresources binnen je AWS- of GCP-omgeving, dus de online store-lees- en schrijfacties, de Spark-clustercompute, de online store-opslag en de S3-opslag landen allemaal op je cloudrekening — niet op die van Tecton. Een team dat via het ene kanaal inricht en via het andere afstemt, vindt altijd een gat. Beslis één keer dat de werkelijke kost van een feature view de som van beide buckets is, en zorg dat je maandeinde-pull zowel de Tecton-factuur als de getagde regels op de cloudrekening omvat.
Stream- en batch feature views verbruiken verschillend
De kostencomponenten verschillen per type feature view, en weten welke je draait vertelt je welke regels je in het oog moet houden.
Stream feature views omvatten online store-lees- en schrijfacties, Spark stream-clustercompute, Tecton Spark streaming compute-kredieten, S3-opslag en online store-opslag. Batch feature views omvatten een vergelijkbare lijst — online store-lees- en schrijfacties, Spark job-clustercompute, Tecton Spark batch compute-kredieten en S3-opslag — minus de streaming-specifieke onderdelen.
De parameters die de rekening beïnvloeden zijn de ontwerpkeuzes die je ML-engineers dagelijks maken. Continue streamverwerking checkpoint en schrijft veel vaker dan verwerking op intervallen, dus het kost meer. Grotere aggregatievensters vragen meer compute. Langere watermarks voor laat-aankomende data verhogen de geheugenvereisten. Clusterconfiguratie prijst elke job direct. Datacompactie verlaagt de opslagkosten en verbetert de leesprestaties. Geen van deze zijn financiële instellingen; het zijn engineering-instellingen met financiële gevolgen, en daarom begint de boekhouding voor dit platform met een gesprek tussen beide teams over welke feature views bestaan en waarop ze zijn afgestemd.
De kostenhiërarchie vertelt je waar het geld naartoe gaat
Tecton's eigen richtlijnen rangschikken de kostenimpact van hoog naar laag, en de volgorde is het onthouden waard omdat het voorspelt waar je verrassingen vandaan komen.
Online store-operaties staan bovenaan. Schrijfacties naar de online store zijn doorgaans de hoogste infrastructuurkost, vooral tijdens backfills — het herberekenen van historische features voor een nieuwe of gewijzigde feature view — of onder continue streamverwerking. Een backfill is een geplande piek: dagen of weken historische berekening en een vloed aan schrijfacties samengeperst in één venster. Als niemand finance waarschuwt dat het eraan komt, ziet de maand waarin het landt eruit als een kostenoverschrijding in plaats van een investering.
Computeresources komen tweede: Spark-clusterkosten voor stream- en batchverwerking, variërend met configuratie en werklast. Opslag komt derde: online store-opslag en leesacties plus S3, doorgaans met lagere impact dan compute en schrijfacties.
De praktische consequentie is dat je rekening wordt gedreven door schrijfacties en compute-gebeurtenissen, niet door hoeveel mensen in de console inloggen. Capaciteitsplanning betekent hier het beheersen van backfills, verwerkingsmodi en aggregatievensters — niet personeelsaantal.
Waarom Productie-Feature-Serving COGS Is
Onder US GAAP omvat de kostprijs van verkochte goederen van een SaaS-bedrijf — de kostprijs van omzet — de directe kosten van het leveren van de dienst waarvoor klanten betalen: hostinginfrastructuur, cloudcompute en -opslag, software van derden ingebed in het product, en al het andere dat meeschaalt met verbruik. Feature-serving voor een productie-ML-product voldoet ruimschoots aan die lat. Wanneer je fraudemodel een transactie scoort, je recommendation engine een feed rangschikt, of je prijsmodel een tarief afgeeft, zijn de online store-leesacties en de pipelines die die features vers houden een even directe leveringskost als de applicatieservers erachter.
Die classificatie is belangrijk omdat ze rechtstreeks doorvloeit naar de brutomarge, het getal dat investeerders, kredietverstrekkers en overnemers gebruiken om te beoordelen of de economische logica van je product werkt. Serving-kosten onder de streep parkeren in algemene operationele kosten blaast de brutomarge op en verbergt het schaalverhaal. Een due-diligence-team zal je grootboek toch herindelen naar een standaard SaaS-COGS-definitie; vanaf het begin juist classificeren betekent dat je eigen dashboards hetzelfde verhaal vertellen als wat een buitenstaander zal berekenen.
Niet elke Tecton-dollar hoort echter in COGS. De splitsing volgt gebruik, niet leverancier:
- Productie-serving is COGS. Online store-lees- en schrijfacties voor live inferentie, de streaming- en batch-pipelines die productie-features vers houden, en de opslag erachter leveren allemaal de klantgerichte dienst.
- Experimentatie en staging zijn operationele kosten. Development feature views, offline experimentatie en staging-omgevingen ondersteunen onderzoek en ontwikkeling, niet levering. Boek ze naar R&D.
- Alleen-training-werk vraagt om beoordeling. Offline feature-berekening die uitsluitend bestaat om de volgende modelversie te trainen, lijkt meer op R&D dan op levering; dezelfde pipeline die de online store voedt voor live serving is COGS. Wanneer één feature view beide doet, alloceer op basis van een verdedigbare driver — getagde clouduitgaven per omgeving is de schoonste die de meeste teams hebben.
Tecton tagt compute-instances en online store-resources per feature view, dus de allocatiedata bestaat in je cloud cost explorer. De boekhoudtaak is één keer de mapping bepalen — welke feature views productie dienen, welke experimentatie — en die vervolgens elke maand toe te passen in plaats van haar bij elke afsluiting opnieuw te bediscussiëren.
Tecton Kopen is Kosten; het Equivalent Bouwen Kan Kapitaal Zijn
Nog één classificatie die het waard is om goed te doen: het team dat Tecton koopt, boekt het verbruik als kosten zoals hierboven beschreven, maar het team dat zijn eigen feature store bouwt op open-source software staat voor een kapitalisatievraag. Intern-gebruikte software ontwikkeld voor je eigen operaties kan in aanmerking komen voor kapitalisatie zodra een project de voorbereidende fase voorbij is, wat engineering-salarissen en infrastructuur omzet in een afschrijvend actief in plaats van een periodekost.
Geen van beide behandelingen is optionele kleur. Als je Tecton draait, kapitaliseer de facturen dan niet alsof je het platform hebt gebouwd. Als je migreert van een zelfgebouwde store naar Tecton, blijft het oude gekapitaliseerde actief afschrijven terwijl het nieuwe verbruik COGS raakt — twee verschillende regels, twee verschillende verhalen, beide tegelijk correct.
Vooruitbetaalde Kredieten en Verplichtingen Zijn Eerst Activa, Later Kosten
Verbruiksplatforms verkopen vaak vooruitbetaalde kredieten of jaarlijkse bestedingsverplichtingen, en de boekhouding voor beide volgt het matching-principe: leg de betaling vast als een actief en neem haar vervolgens als kosten op naarmate het voordeel wordt verbruikt. Een dollar die vooraf naar een leverancier wordt overgemaakt, is nog geen kost van wat dan ook. Het wordt COGS wanneer de kredieten opbranden tegen productie-serving, R&D wanneer ze opbranden tegen experimentatie, en een verlies als ze ongebruikt verlopen.
In de praktijk betekent dat drie boekingen, niet één. Wanneer je kredieten koopt, debiteer je een vooruitbetaald actief en crediteer je kas. Elke maand verminder je het saldo met wat daadwerkelijk is verbruikt — productieverbruik naar COGS, staging-verbruik naar R&D. Als de kredieten een vervaldatum hebben, zet die in de agenda; een verlopen saldo is een echt verlies dat een geplande afschrijving verdient, geen ontdekking tijdens de opruiming van volgend jaar.
Take-or-pay-minimums voegen daar een accrual bovenop toe. Als je contract je verplicht tot een minimale kwartaalbesteding, ben je het hoogste van werkelijk verbruik en het minimum verschuldigd. Wanneer het verbruik tegen het einde van de periode onder de verplichting zakt, accrue dan het tekort dat je toch zult verschuldigd zijn. De factuur komt later, maar de verplichting bestaat op de balansdatum, en de afsluiting moet die weerspiegelen.
Afstemmen aan het Maandeinde: Twee Rekeningen, Één Waarheid
Tecton publiceert factureerbare gebruikslogboeken — gedetailleerde CSV-records van platformgebruik en hoe dat zich vertaalt in kredieten, die ruwweg een dag of twee na het gebruik in je eigen object storage landen. Gecombineerd met de getagde clouduitgaven zijn deze logs de meterstanden waarop je reconciliatie hangt. Behandel het maandelijkse proces als het tegen elkaar matchen van drie bronnen: de gebruikslogboeken, de Tecton-factuur en de cloudrekening.
Een werkbare afsluit-checklist ziet er zo uit:
- Pull de gebruikslogboeken voor de volledige maand. Bevestig dat de kredieten van elke productie-feature-view en elke experiment aanwezig zijn, inclusief de laatste twee dagen — de log-vertraging betekent dat een afsluiting op de eerste van de maand data mist. Wacht ofwel op de logs of accrue de laatste dagen vanuit run-rate en corrigeer volgende maand.
- Accrue de niet-gefactureerde Tecton-zijde. Zoals bij de meeste verbruiksfacturering komt de factuur na de periode die ze dekt. Boek een accrual voor de geschatte kredieten van de maand naar COGS en R&D op basis van de omgevingssplitsing, en reverse en corrigeer wanneer de factuur arriveert.
- Pull getagde clouduitgaven. Filter je cloud cost explorer op de feature-view-tags voor dezelfde periode. Dit is de tweede bucket — Spark-clusters, online store-operaties, opslag — en die moet op dezelfde manier worden gesplitst in prod versus staging.
- Stem logs af op factuur op cloudrekening. Gebruikslogboeken moeten aansluiten op de Tecton-factuur; getagde cloudregels moeten in dezelfde richting bewegen. Een backfill-maand laat beide pieken. Een factuur die afwijkt van de logs is een factureringsvraag om nu aan te kaarten, niet bij verlenging.
- Schrijf vooruitbetalingen en verplichtingen af. Neem verbruikte kredieten als kosten op uit het vooruitbetaalde actief, accrue eventuele tekorten op verplichtingen, en bevestig dat resterende saldi er nog bruikbaar uitzien vóór vervaldatum.
De meest voorkomende fout is stap drie — de Tecton-factuur nauwgezet afstemmen terwijl de cloudzijde-uitgaven zich verschuilen in een grotere infrastructuurrekening onder generieke hosting. Als je cloudafschrift één samengevoegde compute-regel toont, los dan de tagging op voordat je iets anders oplost. Niet-getagde uitgaven kunnen niet worden gealloceerd, en niet-gealloceerde uitgaven belanden altijd ergens verkeerd.
Een concrete maand in de boeken
Stel dat je ML-platform in januari Tecton-kredieten verbrandt die gefactureerd worden als $40.000 tegen productie-serving en $8.000 tegen experimentatie, plus $12.000 getagde clouduitgaven verdeeld als $9.500 productie en $2.500 staging. Je hebt ook $100.000 aan kredieten vooruitbetaald aan het begin van het kwartaal. Januari wordt zo geboekt:
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Assets:Prepaid:Tecton-Credits USD
2026-01-01 open Expenses:CostOfSales:Feature-Serving USD
2026-01-01 open Expenses:Research:ML-Experimentation USD
2026-01-01 open Liabilities:Accrued:Tecton USD
2026-01-01 open Liabilities:Accrued:Cloud USD
2026-01-05 * "Tecton" "Prepay Q1 consumption credits"
Assets:Prepaid:Tecton-Credits 100000.00 USD
Assets:Cash:Operating -100000.00 USD
2026-01-31 * "Tecton" "January credit consumption, prod serving plus experimentation"
Expenses:CostOfSales:Feature-Serving 40000.00 USD
Expenses:Research:ML-Experimentation 8000.00 USD
Assets:Prepaid:Tecton-Credits -48000.00 USD
2026-01-31 * "Cloud" "January tagged feature-platform infra, prod plus staging"
Expenses:CostOfSales:Feature-Serving 9500.00 USD
Expenses:Research:ML-Experimentation 2500.00 USD
Liabilities:Accrued:Cloud -12000.00 USDHet patroon generaliseert: vooruitbetaling is een actief, verbruik verplaatst het naar kosten per omgeving, en de cloudzijde accrueert apart omdat ze apart factureert. Als je team de boeken in platte tekst bijhoudt, strekken de kostentracking-patronen in de documentatie zich van nature uit naar een splitsing per feature view, en de dashboard-weergaven maken de prod-versus-staging-trend maand na maand zichtbaar.
Fouten Die de Marge Verkeerd Voorstellen
Vier fouten komen herhaaldelijk voor bij teams die verbruiksgefactureerde ML-infrastructuur draaien. Elk is goedkoop te voorkomen en duur te ontwarren over herziene periodes.
De Tecton-factuur boeken als de volledige kost. De factuur is één bucket. Elke maand voegen de cloudzijde-compute, online store-operaties en opslag een tweede bucket van vergelijkbare omvang toe, en die weglaten onderschat COGS met ruwweg de helft. Stem beide af of rapporteer geen van beide.
Vooruitbetalingen als kosten boeken op het moment van betaling. Een aankoop van $100.000 aan kredieten is geen kost van $100.000 in de maand dat de overschrijving plaatsvindt. Het is een actief dat in kosten wordt omgezet naarmate kredieten opbranden. Kosten boeken bij betaling front-loadt het kwartaal, ontneemt latere maanden hun werkelijke kost, en maakt verbruikstrends onleesbaar.
Staging via COGS laten lopen. Experimentatie-feature-views, offline backfills voor modelonderzoek en staging-omgevingen zijn R&D. Ze vermengen met serving-kosten overdrijft COGS en straft de brutomarge voor werk dat nooit een klant heeft aangeraakt. De feature-view-tags bestaan juist om deze splitsing eerlijk te houden — gebruik ze.
De accrual overslaan. Verbruik wordt achteraf gefactureerd, gebruikslogboeken lopen een dag of twee achter, en de cloudrekening komt nog later. Een afsluiting zonder accrual boekt een gedeeltelijke maand als een volledige, en de ontbrekende dagen duiken volgende maand op als een mysterieuze afwijking. Accrue vanuit run-rate en corrigeer wanneer de documenten arriveren.
Je laatste nuttige stap deze maand is klein: open je cloud cost explorer, filter op de feature-view-tags, en bevestig dat het getal dat je ziet het getal in je boeken is. Als de twee elkaar nooit hebben ontmoet, heb je zojuist het gat gevonden dat dit artikel is geschreven om te dichten.
