Your Tecton invoice says one number, your AWS bill quietly carries the rest, and neither document calls itself the full cost of serving features. That split is the trap. Tecton prices on consumption — compute credits for the pipelines it runs plus the cloud resources those pipelines consume inside your own account — so the invoice you receive from Tecton is only ever part of the spend. If your books record the invoice and stop there, your cost of goods sold is understated, your gross margin is overstated, and every pricing decision you make on top of that margin rests on a number that was never complete.
This post explains how Tecton actually meters and bills, why production feature serving belongs in cost of goods sold, how to handle prepaid credits and consumption commitments, and how to reconcile all of it at month-end so every dollar lands in the right account.
How Tecton Meters: Feature Views, Not Seats
Tecton is a managed feature platform for machine learning. You define transformations over your data as feature views, Tecton computes them on batch or streaming pipelines, and it serves the results to your models — an offline store for large-scale training retrieval and an online store for low-latency retrieval during live inference. There are no per-seat licenses to count. You pay for what the platform consumes while computing, storing, and serving your features.
That consumption falls into two buckets that bill in two different places, which is the first thing to internalize.
The first bucket is Tecton credits. These cover the compute Tecton manages on your behalf: Spark streaming compute credits for stream feature views, Spark batch compute credits for batch feature views. Your usage of the platform translates into credits, and the credits appear on the Tecton invoice.
The second bucket is the infrastructure itself, and it bills through your own cloud account. Tecton manages compute and storage resources inside your AWS or GCP environment, so the online store reads and writes, the Spark cluster compute, the online store storage, and the S3 storage all land on your cloud bill — not on Tecton's. A team that provisions through one channel and reconciles through the other will always find a gap. Decide once that the true cost of a feature view is the sum of both buckets, and make sure your month-end pull covers both the Tecton invoice and the tagged lines on the cloud bill.
Stream and batch feature views consume differently
The cost components differ by feature-view type, and knowing which you run tells you which lines to watch.
Stream feature views carry online store reads and writes, Spark stream cluster compute, Tecton Spark streaming compute credits, S3 storage, and online store storage. Batch feature views carry a similar list — online store reads and writes, Spark job cluster compute, Tecton Spark batch compute credits, and S3 storage — minus the streaming-specific pieces.
The parameters that move the bill are the design choices your ML engineers make every day. Continuous stream processing checkpoints and writes far more often than interval-based processing, so it costs more. Larger aggregation windows need more compute. Longer watermarks for late-arriving data raise memory requirements. Cluster configuration prices every job directly. Data compaction cuts storage cost and improves read performance. None of these are finance settings; they are engineering settings with finance consequences, which is why the accounting for this platform starts with a conversation between the two teams about which feature views exist and what they are tuned to do.
The cost hierarchy tells you where the money goes
Tecton's own guidance ranks cost impact from highest to lowest, and the ordering is worth memorizing because it predicts where your surprises will come from.
Online store operations sit at the top. Writes to the online store are typically the highest infrastructure cost, especially during backfills — recomputing historical features for a new or changed feature view — or under continuous stream processing. A backfill is a planned spike: days or weeks of historical computation and a flood of writes compressed into one window. If nobody warns finance it is coming, the month it lands looks like a cost overrun instead of an investment.
Compute resources come second: Spark cluster costs for stream and batch processing, varying with configuration and workload. Storage comes third: online store storage and reads plus S3, generally lower impact than compute and writes.
The practical consequence is that your bill is driven by writes and compute events, not by how many people log into the console. Capacity planning here means governing backfills, processing modes, and aggregation windows — not headcount.
Why Production Feature Serving Is COGS
Under US GAAP, a SaaS company's cost of goods sold — cost of revenue — includes the direct costs of delivering the service customers pay for: hosting infrastructure, cloud compute and storage, third-party software embedded in the product, and anything else that scales with usage. Feature serving for a production ML product clears that bar easily. When your fraud model scores a transaction, your recommendation engine ranks a feed, or your pricing model quotes a rate, the online store reads and the pipelines that keep those features fresh are as direct a delivery cost as the application servers behind them.
That classification matters because it flows straight into gross margin, the number investors, lenders, and acquirers use to judge whether your product economics work. Parking serving costs below the line in general operating expense inflates gross margin and hides the scaling story. A diligence team will re-map your GL to a standard SaaS COGS definition anyway; classifying correctly from the start means your own dashboards tell the same story an outsider will compute.
Not every Tecton dollar belongs in COGS, though. The split follows use, not vendor:
- Production serving is COGS. Online store reads and writes for live inference, the streaming and batch pipelines that keep production features fresh, and the storage behind them all deliver the customer-facing service.
- Experimentation and staging are operating expense. Development feature views, offline experimentation, and staging environments support research and development, not delivery. Book them to R&D.
- Training-only work needs judgment. Offline feature computation that exists solely to train the next model version looks more like R&D than delivery; the same pipeline feeding the online store for live serving is COGS. When one feature view does both, allocate by a defensible driver — tagged cloud spend per environment is the cleanest one most teams have.
Tecton tags compute instances and online store resources by feature view, so the allocation data exists in your cloud cost explorer. The accounting task is deciding the mapping once — which feature views serve production, which serve experimentation — and then applying it every month instead of re-litigating it at each close.
Buying Tecton is expense; building the equivalent may be capital
One more classification worth getting right: the team that buys Tecton expenses the consumption as described above, but the team that builds its own feature store on open-source software faces a capitalization question instead. Internal-use software developed for your own operations can qualify for capitalization once a project passes the preliminary stage, which turns engineering salaries and infrastructure into an amortizing asset rather than a period expense.
Neither treatment is optional color. If you run Tecton, do not capitalize its invoices as though you built the platform. If you migrate from a self-built store to Tecton, the old capitalized asset keeps amortizing while the new consumption hits COGS — two different lines, two different stories, both correct at once.
Prepaid Credits and Commitments Are Assets First, Expense Later
Consumption platforms commonly sell prepaid credits or annual spend commitments, and the accounting for both follows the matching principle: record the payment as an asset, then expense it as the benefit is consumed. A dollar wired to a provider in advance is not yet a cost of anything. It becomes COGS when the credits burn against production serving, R&D when they burn against experimentation, and a loss if they expire unused.
In practice that means three bookings, not one. When you buy credits, debit a prepaid asset and credit cash. Each month, draw the balance down by what was actually consumed — production consumption to COGS, staging consumption to R&D. If the credits carry an expiry date, calendar it; an expired balance is a real loss that deserves a planned write-off, not a discovery during next year's cleanup.
Take-or-pay minimums add an accrual on top. If your contract commits you to a minimum quarterly spend, you owe the greater of actual consumption and the minimum. When consumption runs below the commitment near period-end, accrue the shortfall you will owe anyway. The invoice will arrive later, but the liability exists at the balance sheet date, and the close should reflect it.
Reconciling at Month-End: Two Bills, One Truth
Tecton publishes billable usage logs — detailed CSV records of platform use and how it translates into credits, landing in your own object storage roughly a day or two after the usage. Combined with the tagged cloud spend, these logs are the meter readings your reconciliation hangs on. Treat the monthly process as matching three sources against each other: the usage logs, the Tecton invoice, and the cloud bill.
A workable close checklist looks like this:
- Pull the usage logs for the full month. Confirm every production feature view's credits and every experiment's credits are present, including the last two days — the log lag means a close run on the first of the month is missing data. Either wait for the logs or accrue the final days from run-rate and true up next month.
- Accrue the unbilled Tecton side. Like most consumption billing, the invoice arrives after the period it covers. Book an accrual for the month's estimated credits to COGS and R&D by environment split, then reverse and true up when the invoice lands.
- Pull tagged cloud spend. Filter your cloud cost explorer by the feature-view tags for the same period. This is the second bucket — Spark clusters, online store operations, storage — and it must be split prod versus staging the same way.
- Reconcile logs to invoice to cloud bill. Usage logs should tie to the Tecton invoice; tagged cloud lines should move in the same direction. A backfill month will spike both. An invoice that diverges from the logs is a billing question to raise now, not at renewal.
- Draw down prepayments and commitments. Expense consumed credits out of the prepaid asset, accrue any commitment shortfall, and confirm remaining balances still look usable before expiry.
The most common failure is step three — reconciling the Tecton invoice meticulously while the cloud-side spend hides inside a larger infrastructure bill under generic hosting. If your cloud statement shows one blended compute line, fix the tagging before you fix anything else. Untagged spend cannot be allocated, and unallocated spend always ends up somewhere wrong.
A concrete month in the books
Suppose your ML platform burns Tecton credits billed at $40,000 against production serving and $8,000 against experimentation in January, plus $12,000 of tagged cloud spend split $9,500 production and $2,500 staging. You also prepaid $100,000 of credits at the start of the quarter. January books like this:
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 USDThe pattern generalizes: prepayment is an asset, consumption moves it to expense by environment, and the cloud side accrues separately because it bills separately. If your team keeps its books in plain text, the cost-tracking patterns in the docs extend naturally to a per-feature-view split, and the dashboard views make the prod-versus-staging trend visible month over month.
Mistakes That Misstate the Margin
Four errors show up repeatedly on teams running consumption-billed ML infrastructure. Each is cheap to prevent and expensive to unwind across restated periods.
Booking the Tecton invoice as the whole cost. The invoice is one bucket. Every month the cloud-side compute, online store operations, and storage add a second bucket of comparable size, and omitting it understates COGS by roughly half. Reconcile both or report neither.
Expensing prepayments at payment time. A $100,000 credit purchase is not a $100,000 expense in the month the wire goes out. It is an asset that converts to expense as credits burn. Expensing at payment front-loads the quarter, starves later months of their true cost, and makes consumption trends unreadable.
Routing staging through COGS. Experimentation feature views, offline backfills for model research, and staging environments are R&D. Mixing them into serving costs overstates COGS and punishes gross margin for work that never touched a customer. The feature-view tags exist precisely to keep this split honest — use them.
Skipping the accrual. Consumption bills in arrears, usage logs lag by a day or two, and the cloud bill lands later still. A close with no accrual books a partial month as a full one, and the missing days surface as a mystery variance next month. Accrue from run-rate, then true up when the documents arrive.
Your last useful step this month is small: open your cloud cost explorer, filter by the feature-view tags, and confirm the number you see is the number in your books. If the two have never met, you just found the gap this post was written to close.
