Your Webhook Bill Is COGS, Not Overhead: Bookkeeping for Event-Driven SaaS on Svix and Hookdeck

Your revenue grew 20% last quarter, but your webhook delivery bill tripled — and you found out from the credit card statement, not your books. If you run an event-driven SaaS product on Svix or Hookdeck, that surprise is practically a rite of passage: one chatty enterprise customer, one retry storm, or one fan-out feature can multiply your event volume while your subscription revenue barely moves. Whether that shows up as a red flag in your gross margin or hides inside a generic "Software Subscriptions" expense depends entirely on how you book it.

Here is how to classify per-message webhook infrastructure correctly, accrue it at month-end before the invoice arrives, reconcile vendor meters against your own event logs, and track the unit economics that tell you when delivery costs are eating your margin.

What Webhook Infrastructure Actually Costs in 2026​

Both major vendors combine a platform fee with metered usage, which is exactly why the bill surprises people: the base fee is predictable, the meter is not.

Svix prices in three tiers. The free tier ($0, 200 messages per second, 30-day payload retention) covers side projects and prototypes. Professional starts at $490 per month with 800 messages per second, 90-day retention, and a 99.99% uptime SLA. Enterprise is custom-priced with a 99.999% SLA, SSO, and on-prem options. Notably, Svix only counts attempted or transformed messages toward usage — retries and messages filtered because an endpoint has no subscribers are free.

Hookdeck follows a similar shape with finer-grained metering. Developer is $0 for up to 10,000 events a month with 3-day retention. Team starts at $39 per month with pay-as-you-go metering and 7-day retention. Growth starts at $499 per month with uptime and latency SLAs and 30-day retention. Every paid plan includes 10,000 events a month; beyond that, delivered events are metered in declining tiers from $3.00 per 100,000 events at low volume down to $0.35 per 100,000 past half a billion events. Throughput above the included 5 events per second per destination is a separate add-on, retries are included, and a static IP costs $100 a month extra.

Run the math on a realistic mid-stage product: 10 million events a month on Hookdeck Team. The first 10,000 are included, roughly 5 million fall in the $3.00 tier ($150), and the next 5 million fall in the $2.00 tier ($100) — about $250 in usage plus the $39 base, or roughly $289 a month. That feels trivial until a misconfigured customer endpoint, your fan-out to per-tenant endpoints, and a new real-time feature quietly 10x the meter. This is a cost that scales with someone else's behavior, which is why it needs its own ledger line instead of a burial in overhead.

COGS, Not Overhead: Why Classification Matters​

The single most important bookkeeping decision here is where the bill lands on your profit and loss statement. For an event-driven SaaS product, webhook delivery is a cost of revenue (COGS) — it is a third-party service embedded directly in what the customer bought. If your product promises "real-time event delivery to your endpoints," the Svix or Hookdeck invoice is as much a direct delivery cost as your AWS hosting bill. Booking it under general software subscriptions or office overhead overstates your gross margin and hides the exact cost that scales with usage.

Gross margin is the number investors, lenders, and acquirers read first: OpenView's benchmark puts good SaaS COGS at 10–20% of revenue, and 2026 stage data puts early-stage SaaS at 50–65% and growth-stage at 65–78%. Every point of webhook spend misclassified into operating expenses flatters that margin today and creates a restatement headache during diligence tomorrow, when someone reclasses it and asks why your "80% margin" business is really a 71% margin business.

The rule of thumb: if you turned off the vendor tomorrow, would customers lose a feature they pay for? If yes, it is COGS. Your internal error-tracking tool is overhead; the pipes that deliver paid event notifications are cost of revenue.

Set Up a Chart of Accounts That Separates the Meter From the Platform​

Give webhook delivery its own sub-accounts so fixed and variable costs never mix. A structure that works for most event-driven products:

• Cost of Revenue
  • Hosting & Compute (AWS/GCP/Fly)
  • Webhook & Event Delivery
    • Svix — platform fee (fixed)
    • Svix — metered overage (variable)
    • Hookdeck — platform fee (fixed)
    • Hookdeck — metered overage (variable)
    • Throughput & add-ons (static IPs, extra retention)
  • Customer support allocation

This split is what makes variance analysis possible: the platform line should barely move, while the metered line should move with event volume. When the metered line jumps 40% and your event count only rose 10%, you know to look for a tier-boundary crossing, a throughput add-on you forgot, or a customer abusing the firehose — instead of staring at a single blended number.

If you keep your books in plain text, the same split is one account hierarchy away. A monthly Hookdeck bill might post like this (see the Beancount syntax docs if you are new to plain-text ledgers):

2026-09-30 * "Hookdeck" "September event delivery - 10.2M events"
  Expenses:Cost-of-Revenue:Webhook-Delivery:Hookdeck:Platform-Fee    39.00 USD
  Expenses:Cost-of-Revenue:Webhook-Delivery:Hookdeck:Metered-Usage  250.00 USD
  Liabilities:Accounts-Payable:Hookdeck                             -289.00 USD

Tag the journal entry with the event count from the vendor dashboard. Six months from now, that tag is how you answer "what did 10 million events cost us in September?" without re-opening a single invoice.

Gross or Net? The Principal-vs-Agent Question When You Resell Delivery​

Many event-driven products charge customers for what the vendor bills you for: per-event overage fees, webhook add-on tiers, or usage-based plans where delivery is a line item. When you resell third-party delivery, ASC 606 requires a principal-versus-agent evaluation to decide whether you report revenue gross (with the vendor bill in COGS) or net (just your markup as revenue).

The test is control: do you control the specified service before it transfers to the customer? Under ASU 2016-08, a principal recognizes revenue gross and records third-party costs in COGS, while an agent — one that merely arranges for another party to provide the service — recognizes only its fee. Indicators of control include primary responsibility for fulfillment, inventory risk, and discretion in pricing.

Most SaaS products land firmly on the principal side. Your customer cannot point their endpoints at your Svix account, cannot call Svix support about your events, and pays the price you set — you control delivery end to end: report the event revenue gross and the vendor invoice as COGS. You would only be an agent if you genuinely pass the customer through to the vendor (the customer holds the vendor relationship and you take a referral cut). Get this wrong in the net direction and you understate both revenue and COGS; get it wrong in the gross direction without control and you overstate both. Either way, document the analysis in a memo — auditors ask for it, and "we always did it this way" is not an answer.

Accrue the Meter Before the Invoice Arrives​

Metered vendors finalize invoices days after the month ends — AWS typically finalizes between the third and fifth of the following month, and usage-based API vendors follow the same pattern. If you close your books on the first and book vendor bills when they arrive, every month-end close either waits on vendors or silently drops a month of delivery cost into the wrong period.

Fix it with a standing accrual. On the last day of the month:

1. Pull the event count from the vendor dashboard or usage API and freeze it (screenshot plus CSV export).
2. Multiply by your effective tier rate to estimate the metered charge; add the fixed platform fee.
3. Post an accrual: debit Webhook Delivery (metered), credit Accrued Vendor Payables.
4. When the invoice arrives, reverse the accrual and book the actual, posting the difference to the same metered account so the true-up stays visible.

Attach the usage export to the journal entry. At 10 million events a month the accrual takes ten minutes; at 500 million it is the difference between a close you can defend and a COGS line that swings wildly because January's spike got booked in February. Revisit the estimate quarterly — tier crossings and throughput add-ons drift your effective rate, and a stale rate turns every true-up into a surprise.

Reconcile the Vendor Meter Against Your Own Event Logs​

You would not pay a freight bill without checking it against your shipment log. Do not pay a per-message bill without checking it against your event pipeline. Metered billing is computed by the vendor's counter, and the vendor's counter has definitions you must understand: Svix excludes retries and filtered messages; Hookdeck includes retries but meters discarded requests separately. A "delivered event" on the invoice may not equal an "event emitted" in your logs.

Build a monthly reconciliation habit:

• Tie the invoice to the dashboard. The invoiced event count should match the vendor's usage view for the period, within rounding. If it does not, open a ticket before you pay, not after.
• Tie the dashboard to your logs. Your emitted-event count times average fan-out (endpoints per event) should approximate delivered attempts. A persistent gap means dead endpoints, misfiring filters, or double-emission bugs — all of which cost money.
• Watch retention windows. Payload and metrics retention is 30 days on Svix Free and 90 on Pro; 3, 7, or 30 days across Hookdeck's tiers. If a dispute surfaces after retention expires, the evidence is gone. Export monthly usage summaries to your own storage as part of the close checklist above.
• Alert on fan-out, not just volume. Total events can look flat while one customer's 60-endpoint configuration quietly multiplies your bill. Track cost per customer for your heaviest event consumers the way an infrastructure team tracks noisy neighbors.

One reconciliation a month catches the two classic failure modes: the retry storm that nobody noticed because delivery "recovered," and the enterprise deal whose per-seat price assumed ten events per user per day while the integration emits ten thousand.

The Unit Economics Worth Tracking​

Aggregate COGS tells you the margin; unit economics tell you whether the next customer helps or hurts. For event-driven SaaS, four ratios carry most of the signal:

• Cost per 1,000 delivered events, by vendor, monthly. This is your blended rate after tiers and add-ons. It should drift down as volume grows (tier discounts) — if it drifts up, you are buying throughput add-ons or sitting in the wrong tier.
• Webhook COGS as a percentage of revenue, overall and per plan tier. A common tripwire is delivery exceeding 5% of revenue on any tier, or growing faster than that tier's revenue for two consecutive quarters.
• Delivery cost per customer for the top decile of event consumers. Compare against their contract value. An enterprise logo paying $2,000 a month while generating $400 in delivery cost has a very different margin than the plan average suggests.
• Gross margin per plan tier with delivery allocated by actual usage, not evenly. Even allocation hides the truth that your "Pro" tier subsidizes three API firehoses.

When a ratio breaches its tripwire, you have four levers, in order of pain: renegotiate the vendor tier (volume commitments buy down per-unit rates), optimize emission (batch, filter, debounce), reprice the heavy tier (usage-based overage that names event delivery), and as a last resort, throttle or degrade delivery for abusive consumers. Margin alerts only work if the underlying accounts are clean — which is why the chart-of-accounts split comes before the dashboard, not after.

Build vs. Buy, Accountant's Edition​

Every webhook-vendor pricing page ships a build-vs-buy matrix, and it is worth reading with an accountant's eye, because the two options hit your financials in completely different places.

Buying is simple: the platform fee and metered usage are period COGS expenses. No asset, no amortization schedule, no impairment test — your gross margin reflects the true delivery cost every month.

Building triggers ASC 350-40, internal-use software. Costs incurred during the application development stage — external direct costs of materials and services, fees paid to third parties to develop the software, payroll for developers assigned to the project — are capitalized as an asset and amortized over the software's useful life. Preliminary-stage work (evaluating vendors, prototyping) and post-implementation costs (training, maintenance, data conversion operations) are expensed as incurred. So the homegrown delivery service shows up as amortization (typically in COGS for a product-embedded system, or R&D-adjacent depending on your policies) plus the ongoing infrastructure to run it — while the engineers' time spent firefighting the queue at 2 a.m. is maintenance expense, not an asset.

Neither treatment is "better," but they are not comparable without adjustment. If you are weighing the build-vs-buy decision, model the buy side as fully loaded COGS against the build side as amortization plus hosting plus the opportunity cost of the team — and remember that if you build first and migrate to a vendor later, the capitalized asset gets impaired down to zero the day you decommission it. That write-off has ended more than one "we will just build webhooks ourselves" story.

Mistakes That Quietly Corrupt Event-Driven Books​

• Burying the meter in a generic subscriptions account. The moment delivery cost shares a line with your password manager, you have lost the ability to see margin erosion. Split it out the month usage billing starts, not the month it hurts.
• Closing on cash timing. Booking metered vendor bills when paid instead of when incurred makes COGS lurch with invoice timing rather than usage. Accrue, then true up.
• Forgetting the add-ons. Throughput tiers, static IPs, extra retention, and annual platform prepaids amortized monthly all belong in delivery COGS. The invoice total and the dashboard's "usage" line are rarely the same number — reconcile to the invoice.
• Ignoring the resale question. If you charge per event, write the principal-vs-agent memo before your first audit, not during it.
• Letting retention expire on evidence. Export usage monthly. The vendor's 3-day or 30-day window will not wait for your dispute.

Keep Your Infrastructure Costs Visible From the First Million Events​

Event volume is the kind of cost that compounds silently: every new customer, endpoint, and retry policy multiplies a meter that bills in arrears and arrives after you close. Classify delivery as COGS from day one, accrue it monthly, reconcile it against your own logs, and track cost per thousand events like the margin lever it is.

As your event pipeline grows, maintaining clear financial records for every vendor meter is essential. Beancount.io provides plain-text accounting that gives you complete transparency and control over your financial data — no black boxes, no vendor lock-in. Get started for free and see why developers and finance professionals are switching to plain-text accounting.