A three-person chaos engineering shop runs a game day for a mid-market fintech client, bills $18,000 for the two-week engagement, and also passes through a $4,000 annual Gremlin or AWS Fault Injection Simulator license the client didn't want to procure directly. Six months later, the founder is staring at a P&L that shows $22,000 in "consulting revenue" and can't answer a simple question: how profitable was the actual engineering work, separate from being an unpaid software reseller?
This is an increasingly common problem. As chaos engineering has moved from a Netflix-only curiosity to a standard line item in enterprise resilience programs, a wave of boutique consultancies has formed around it — running resilience audits, facilitating game-day workshops, and building automated fault-injection pipelines for clients who don't want to hire a dedicated SRE team. The engineering work is well understood. The bookkeeping usually isn't, because these firms are running two fundamentally different businesses inside one entity: a services business with lumpy, project-based revenue, and a software resale business with recurring, low-margin, pass-through cash flow. Mixing them in your chart of accounts hides which one is actually making you money.
Why Chaos Engineering Firms Have This Problem More Than Most Consultancies
A generic strategy consultancy bills for time and calls it a day. A chaos engineering practice typically has three or four distinct revenue streams running simultaneously:
- Resilience audits — a fixed-fee or hourly engagement reviewing a client's architecture, dependency graphs, and failure points before any fault injection happens. This is diagnostic work, usually delivered as a report plus a prioritized experiment backlog.
- Game-day facilitation — the actual live event where the team plans failure scenarios, runs them against staging or production, and coaches the client's engineers through the incident response. Game days test not just the system but the humans and runbooks around it, which is why they're priced and scoped differently from ongoing automated chaos testing.
- Automation and platform build-out — standing up recurring chaos experiments in CI/CD, which is closer to software engineering delivery than a workshop and often gets billed as a project with milestones.
- Tooling resale or pass-through — reselling or administering licenses for platforms like Gremlin, Harness Chaos Engineering, or configuring cloud-native services like AWS Fault Injection Simulator and Azure Chaos Studio on the client's behalf, sometimes at a markup, sometimes at cost as a convenience.
Each of these has a different cost structure, a different margin profile, and — critically — a different revenue recognition treatment under ASC 606 if you're a US-based entity preparing GAAP-adjacent books for a bank, investor, or your own decision-making. Lump them into one "Consulting Income" account and you lose the ability to see that your game-day facilitation carries an 80% margin while your tooling resale carries an 8% margin and is barely worth the administrative overhead.
Structuring Your Chart of Accounts by Revenue Stream, Not by Client
The single highest-leverage bookkeeping change a chaos engineering consultancy can make is splitting revenue accounts by type of work delivered, not by client or by invoice. A typical setup looks like:
Income:Consulting:ResilienceAudits
Income:Consulting:GameDayFacilitation
Income:Consulting:AutomationBuildOut
Income:ToolingResale:Licenses
Income:ToolingResale:CloudUsagePassThroughWhen you invoice a client for a bundled engagement — say, a resilience audit followed by a game day, with a Gremlin license included — that single invoice needs to be split across at least three of those accounts on the books, not booked as one lump "Project X — $22,000" line. In double-entry, plain-text formats like Beancount, this is a single transaction with multiple postings:
2026-07-16 * "Fintech Client Co" "Resilience audit + game day + Gremlin license"
Assets:AccountsReceivable:FintechClientCo 22000.00 USD
Income:Consulting:ResilienceAudits -6000.00 USD
Income:Consulting:GameDayFacilitation -12000.00 USD
Income:ToolingResale:Licenses -4000.00 USDThat one transaction, once it exists, lets you run a real profitability report by service line at any point — instead of reconstructing it from memory or old proposals when your accountant asks in March why margins look inconsistent.
The Tooling Resale Trap: Pass-Through vs. Markup vs. Agency
Reselling or administering third-party chaos engineering tooling licenses is where these firms most often get their books — and their tax treatment — wrong. There are three distinct arrangements, and they should never share a ledger account:
- Pure pass-through: You pay Gremlin $4,000 for a license, invoice the client exactly $4,000, and take no markup. Some firms book this net (only the margin, which is $0) rather than gross. If your engagement letter establishes you as purchasing agent for the client rather than reseller of record, this may qualify as agent-versus-principal treatment under ASC 606 — meaning you'd record the vendor payment and client reimbursement as a wash rather than inflating both revenue and COGS. This matters because it changes your top-line revenue number, which affects everything from loan covenants to how a buyer values your firm on a revenue multiple.
- Marked-up resale: You buy the same license for $4,000 and bill the client $5,000, keeping a $1,000 spread. Here you're acting as principal — you control the good or service before it transfers to the customer — and should record the full $5,000 as revenue with $4,000 as cost of goods sold, not net it down to $1,000. Booking it net understates both revenue and COGS lines that a buyer or lender may want to see separately.
- Client procures directly: The cleanest arrangement — the client has their own Gremlin or FIS contract, and you simply administer it. Nothing touches your books at all, which is why more consultancies are pushing clients toward direct procurement as they scale: it removes an entire low-margin, cash-flow-timing-risk business line from their P&L.
Whichever pattern you use, pick one per client relationship and be consistent — mixing agent and principal treatment for the same vendor across different clients, without a documented reason, is exactly the kind of inconsistency that turns a routine bookkeeping review into a drawn-out one.
Recognizing Revenue on Fixed-Fee Audits vs. Milestone-Based Game Days
Resilience audits and game-day workshops are usually sold as fixed fees, which under ASC 606 doesn't mean "recognize it all when the invoice is paid." The standard requires recognizing revenue as the performance obligation is satisfied — either at a point in time or over time, depending on whether the client receives and consumes the benefit as you deliver it.
- A resilience audit delivered as a single report at the end of a two-week engagement is usually point-in-time recognition: nothing hits revenue until the report is delivered and accepted, even if you invoiced 50% up front. That deposit sits in a liability account (
Liabilities:DeferredRevenue:ResilienceAudits) until delivery. - A multi-day game-day engagement with daily deliverables — failure scenario docs, incident timelines, a final retro — often qualifies for over-time recognition, since the client is receiving and using value incrementally rather than in one lump delivery at the end.
- Automation build-out with contractual milestones (staging pipeline live, production experiments scheduled, dashboard handed over) should be recognized milestone-by-milestone, which also happens to make cash flow forecasting dramatically easier since you're not waiting on one large payment at project close.
Getting this wrong doesn't just create an audit headache later — it distorts your own read on the business in real time. A firm that books a $30,000 deposit as revenue the day it lands, then delivers the audit two months later, will look far more profitable in month one and far less profitable in month three than it actually is, which is a bad basis for deciding whether to hire that next engineer.
Tracking Utilization and True Margin Per Engagement Type
Once revenue is split correctly, the next step is mapping cost against it. Chaos engineering consultants are typically billed out at senior rates, so labor cost allocation matters more here than in lower-margin service businesses. For each engagement type, track:
- Direct labor hours against the specific engagement (not just "consulting hours" broadly) — this is what tells you a resilience audit that was scoped for 40 hours actually took 65, and needs repricing next time.
- Tooling costs allocated to the specific client relationship that drove the license purchase, not lumped into a general software expense line.
- Travel and on-site costs for in-person game days, which can materially change the margin on an otherwise identical remote engagement.
The payoff is a per-engagement-type margin report that actually tells you something: many firms in this space find that resilience audits and automation build-out carry the strongest margins because they're pure engineering time, while facilitated game days — despite commanding premium day rates — carry thinner margins once senior facilitator time, travel, and pre-event scenario design are fully loaded in. Without separated books, that's invisible; with it, it's a straightforward pricing conversation with your next prospect.
Keep the Engineering Discipline in Your Financial Records Too
There's a natural parallel here that chaos engineering practitioners tend to appreciate immediately: the whole discipline is built on the idea that you can't trust a system you haven't tested, and that opaque, hard-to-inspect infrastructure hides the failure modes that eventually take you down. The same is true of a spreadsheet or a black-box accounting SaaS tool that nets your tooling resale against your consulting revenue without you asking it to — you don't find out your margins were wrong until the damage is done. Plain-text, version-controlled books mean every posting is inspectable, diffable, and auditable the same way you'd want your infrastructure-as-code to be, and separating revenue streams at the transaction level (not reconstructed later from memory) is what actually makes a monthly profitability review possible instead of a monthly archaeology project.
Simplify Your Financial Management
As your chaos engineering practice grows past a founder-led shop into a team with multiple concurrent engagements, keeping resilience-audit revenue, game-day facilitation, and tooling resale cleanly separated is what makes pricing decisions and margin analysis possible at all. Beancount.io offers 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 technical consultancies are switching to plain-text accounting.