I’ve been to a lot of AI events lately. More than usual. Something has shifted since December — and it’s moving at an exponential pace.

Both in the tools. And in the rooms.

It shows up when someone demos what they’ve actually built. When the reality of what’s possible lands in a room full of people who didn’t know it was possible yet. It’s not excitement exactly. It’s quieter than that. A little unsettling. The kind of quiet where everyone is doing the same mental calculation and nobody wants to say it out loud.

I’ve been sitting with that feeling for a few months. Yesterday, I finally got to do something about it.

We ran the largest AI share session we’ve ever done at Gaapsavvy. 670 invites. 160 practitioners showed up — controllers, revenue leads, CAOs from 100+ enterprise tech companies, 90% audited by Big 4 firms. No panels. No vendor demos. Just practitioners telling each other what’s actually happening.

I started the way I always do. With a practice poll.

Your CFO just sent a company-wide email. ‘We’re going all-in on AI for finance by Q2.’

A. Nod confidently, add “AI strategy” to your LinkedIn, and figure out what that actually means later.

B. Raise your hand and ask has anyone actually done this yet? — and watch the whole room go quiet.

80 responses. 90% Big 4 audited. 52% A. 48% B.

I’ll tell you something about that poll: I iterated on the question with Claude for quite some time, trying to get at the heart of it. When the results came in, my co-facilitator Jim said: “This is way more split than I expected.”

My answer: “That’s because we’re pragmatists.”

Both answers are honest. And I feel both, completely.

Here’s what I want to say before we get into the data.

For the first time in my career, the thing standing between accounting teams and what’s possible isn’t the tools, the budget, or even the access. It’s just the learning. That’s both the most encouraging thing I can tell you, and the most demanding.

The models and tools are finally ready. The only thing left is us.

Here’s the thing the accounting world doesn’t hear enough: they didn’t fully work for us before. The tools you’ve been hearing about for two years just became capable enough to actually use. Even if you felt behind. You were waiting for something that wasn’t ready yet. It just became ready. The timeline starts now.

To put some context around the pace: in the last six weeks alone, over 250 model releases across the major labs. Claude’s context window hit one million tokens — your entire contract portfolio, every policy memo, every prior audit conclusion, all loaded at once. Claude Cowork launched, meaning AI can now use your actual computer while you’re in a meeting. Claude Code revenue doubled since January 1st. Engineers have stopped coding without it.

This is not a slow trend you missed. This is a wave that broke last month.

The thing about exponential: it doesn’t feel exponential while it’s happening. It feels like you blinked. The question isn’t whether you’ve caught up — it’s whether you’re learning fast enough to keep up with something that keeps doubling.

That’s what learning in community is really about. Not just sharing use cases. Learning together, fast, in a moment when learning alone is almost impossible.

Let’s dive in.

This article is brought to you by Everest Systems

Most ERPs weren’t designed for AI. They were built for stability — which means when you try to layer automation on top, you’re testing blind, deploying into production, and hoping nothing breaks.

Everest does it differently. AiSpecify lets finance and ops teams build custom apps using natural language — no code, no IT ticket. Live Sandbox lets you test and validate those changes against real data across your systems, before anything goes live.

The frontier models are ready. Now your ERP needs to be too.

See how Everest works →

Subscribe now

What does enterprise finance actually have access to?

Engineering teams have been using frontier models for close to a year. Finance teams at the same companies are just now getting approval.

That gap — same company, different floor — is what the data shows.

Q: What tools does your company actually let you use? ( i.e. IT approved)

Google Gemini leads at 53% — mostly because it ships with Google Workspace and doesn’t require a separate approval conversation. Claude and ChatGPT Enterprise are tied at 38% each. NotebookLM at 34%. Copilot at 23%.

But the tie between Claude and ChatGPT tells only part of the story.

A migration from ChatGPT to Claude

Of companies with Claude approved, 46% have dropped ChatGPT entirely. They didn't add Claude — they replaced ChatGPT with it.

One controller said it directly:

“We had ChatGPT, then moved on to Claude. We don’t have GPT anymore — now it’s just Claude and Gemini.”

Enterprise security teams are making deliberate choices. The data shows which way they're moving.

Worth noting: Anthropic had a rough week — they accidentally leaked Claude Code source code via a packaging error. No customer data involved. Claude Code is the developer CLI engineers use to write code — a different product from Claude Enterprise, which is what your security team is approving. I'm mentioning it because you probably saw the headlines, and that's what we do here.

Getting Claude through InfoSec — some helpful accelerators

For standard Claude: the enterprise agreement is the unlock. Multiple security teams confirmed they got comfortable once a true enterprise agreement was in place. Same with Gemini — one team said IT had concerns about the Pro tier but the enterprise version resolved them immediately.

Claude Cowork is different. It’s currently in beta, and enterprise agreements don’t automatically cover beta products. One team that got it approved described making specific concessions around folder access and going through additional security review. They got there — but it was a longer, more detailed conversation than approving standard Claude.

If you’re trying to get Cowork through InfoSec, go in knowing this. It’s not a blocker. It’s just a different conversation.

And you have standing to have it. 38% of this community — 90% Big 4 audited, 42% already public — has Claude enterprise-approved. Print the chart. That’s your peer group. 👆

What’s actually happening on the ground

Across five share sessions this quarter, 51 documented use cases from 30 companies. The maturity picture: 49% in production. 29% in progress. 12% prototype. The "we're exploring" era is over for most of this community.

What have you done vs. what do you want to crack in the 6 months?

Two-thirds of the room has used AI for contract review or technical memo drafting. There's a reason those two lead: Klarity and Numeric spent years teaching the market that these were the places to start. So when practitioners answer this poll, they're reporting what the industry told them was possible — and what they've now proven works. One-third have built something beyond that. 51% want to build something in the next six months.

One practitioner put the moment perfectly: “Back in the day, everyone had their own Excel workbook. Now we all have our own AI workflows on our desktops.” The proliferation has already happened. The next question — how to centralize, govern, and share — is the same one we asked about spreadsheets. Just ten times faster.

I showed the community what I’ve been building to help organize community shares— an excel use case tracker and an AI index website, both created maintained entirely by Claude Cowork. I don’t populate any of the fields. I drop a transcript into the folder, it populates any new use cases, or tools. Next meeting, another transcript update. The reaction in the chat wasn’t “wow, AI is amazing.” It was quieter. More like: oh. that would make my meetings actually useful.

That shift — from impressed to capable — is the one I’m trying to create every time I show something instead of just describing it.

The conversation kept coming back to the same tension: Finance and engineering are at the same companies, using different languages, sitting on each other's data.

The data layer is the real bottleneck. The most sophisticated teams aren’t stuck on which AI to use. They’re stuck on getting clean data out of engineering. Usage data sits with the AI team. Capitalization data sits with the dev team. Finance is still waiting on monthly extracts. One controller framed it perfectly: “How do we create better data accessibility throughout the organization that we can then put an AI layer on top of?” The AI is ready. The pipes aren’t.

The best reframe I heard all session. Someone pushed back: aren’t these just accounting projects with “AI” in the name? It was exactly the right question. And by the end of the discussion, he’d answered it himself: AI’s highest-leverage use in accounting right now is getting you out of the business of normalizing unstructured data. Five hundred emails. Contracts written in paragraphs. Sales orders that arrive as sentences your shared services team has never seen. The AI handles the transformation so practitioners can do the judgment. That’s not a small thing. That’s the thing that was eating the hours.

Where are you feeling pressure right now?

60% are feeling pressure from leadership — with no clear path forward. 16% are leading the initiative themselves. 13% have no pressure at all. Only 3% said they’re stuck waiting for InfoSec.

That surprised me too. The bottleneck people experience as an access problem is usually something else. It’s not knowing what use case to propose. It’s not having data in the right shape. It’s not knowing where to start.

Then someone asked the really hard question: how do we frame KPIs that report up without it sounding like headcount reduction?

The room got a little quiet. Then the expected answers came — speed and accuracy, measured simply. One person with the tool, one without. Time to completion. Error rate. Hours to first draft. Real, measurable, safe to show a CFO.

But here’s the reframe I keep thinking about: at NVIDIA, engineers are literally measured on how many tokens they use. That’s their productivity metric. Accounting doesn't have that language yet — but we're about to need it.

If you’re in the 60%, you’re the norm. The pressure isn’t a sign you’re behind. It’s a sign you’re paying attention.

The one thing AI still can’t do

I was at an event a few weeks ago where a panel was asked: what is the one thing AI can’t do right now?

I didn’t listen to the answers. I already knew mine.

Take responsibility.

AI can generate infinite content. It can normalize unstructured data, draft your memos, build your flux analysis, scour 12 years of Box files to find a variance from 2014. It is getting very, very good at all of it, faster than any of us expected.

But when it gets it wrong — and it will get it wrong — it cannot own that. It cannot stand in front of your auditors and say: this is my judgment, here is my reasoning, and I’m accountable for this conclusion.

That’s still yours. That’s always going to be yours.

I‘ve been thinking a lot lately about what it means to run community in a moment when it is so noisy I can barely hear myself think, when attention is the scarcest resource we have, and when every vendor and consultant and LinkedIn connection is competing for a piece of it.

The thing I keep coming back to: The thing AI can’t do, is show up. It can’t be in the room when the air changes. It can’t notice the silence. It can’t decide, together, to stop performing certainty and start actually sharing.

We are only limited by our capacity to learn. That’s terrifying if you’re trying to do it alone. Not so much if you're not.

We’re in this together. Whether we know it or not. But I think it’s how we’re going to figure it out.

Angela

What’s Coming up:

We’re running two events in April for exactly this reason — one hands-on session at Deloitte SF where you get to actually play, and one where you get to see what it looks like when a team that builds these tools uses them on their own finance problems.

Both are worth your time.

April 15 — AI in Finance Lab half day, in person, hands on session @ Deloitte SF, co-hosted with Coterie CFO. I will be teaching AI Fundamentals, and you have space to play with all the frontier models - FULL

April 17 — “Built Between Meetings: How Anthropic’s Finance Team Actually Uses Claude” virtual with Adam Dix, head of FinOps. Must be a Gaapsavvy community member . No recording. Adam shares his learning journey and demos his builds. Worth it. Join here⭐

Want to see Claude Cowork, Excel plugins, and agentic workflows in action? Devon and I spent an afternoon playing with it and discovering new features — watch here.

From real practitioners, for learning purposes only. Polling data shows industry leans, not final positions. Always work with your auditors before implementing anything new.

Subscribe now

I’m starting the year a bit behind schedule, and I’ve decided that imperfection is the muscle I’m intentionally building this year.

In hindsight, the delay helped. It gave me time to pause and reflect—a prompt I use often, both for myself and for AI. That pause created space to think about what actually makes us effective as subject matter experts.

It isn’t just knowing the rules.

It’s the curation of context.

If you’ve been feeling overwhelmed by AI—by the tools, the hype, the pressure to “keep up”—I want to offer a different frame: You already have the most important skill. You’ve been doing it for years.

Let me show you what I mean.

This newsletter is brought to you for free by:

Simplify Complex Revenue Recognition Automate revenue recognition, gain real-time insights, and ensure ASC 606 / IFRS 15 compliance—all while closing books faster

A Note on Community

Over the past year, I’ve been fortunate to build a community of 600+ technical accountants through Gaapsavvy. What I’ve learned from hosting shareforums and knowledge sessions is that we all have something unique to contribute.

Some people are building automation tools. Others are vibe coding reconciliations. Some are diving deep into technical guidance interpretations.

This article shares what I’ve been learning: context engineering for technical accounting. It’s not the only approach to AI, and it’s not right for every situation. But it’s what I’ve been figuring out, and I’m sharing it because that’s what we do in community—we learn, we share, we help each other navigate complexity.

If this resonates with you, read on. If your focus is elsewhere (automation, operational accounting, tool-building), that’s valuable too. We need all of it.

📋 In this article, you’ll learn:

• Why context engineering matters for technical accounting (not just generic AI tips)

• How AI actually processes information—and why most prompts fail

• The 8-step framework I use to set up persistent context for revenue recognition, equity, and leases

• Real examples from pricing analysis to organizational workflows

The Skill You Didn’t Know You Had

Last year I came across an article from Anthropic that described a shift from prompting to Context engineering.

“Context engineering is the art and science of curating what will go into the limited context window from that constantly evolving universe of possible information. In contrast to the discrete task of writing a prompt, context engineering is iterative and the curation phase happens each time we decide what to pass to the model.”

When I saw this, it made me smile. Because context engineering is exactly what we do when we write technical accounting memos.

Think about it: When you’re researching a complex revenue recognition question, you don’t dump ASC 606 into a memo. You:

• Identify the core issue and what questions need answering—then analogize to questions in interpretive guides and understand how each answer affects the next

• Pattern match against prior transactions you’ve seen—digging into past experiences stored in your memory

• Pull in only the relevant guidance from hundreds of pages of literature to build a position

• Reference prior conclusions and precedents—benchmarking to SEC filings, inquiries, and industry peers

• Test your logic iteratively with managers and auditors, arguing the position from different perspectives

• Explain why something matters—documenting your reasoning, refining questions, and iterating until the logic holds

That’s context engineering. You’re taking a massive universe of information and curating the smallest possible set of high-signal inputs that lead to a decision.

The difference now? You’re not just engineering context for other humans. You’re engineering it for machines too.

Why AI Fails (And Why Reasoning Models Don't Fix Everything)

Here’s what I’ve observed: AI models don’t fail because they lack capability. They fail because their attention mechanism gets overwhelmed.

Attention is how AI models decide what to focus on. Think of it like highlighting important sentences while reading—except the AI does this mathematically, comparing every word to every other word to figure out what’s relevant. As context grows, this “attention budget” gets stretched increasingly thin. It’s like trying to highlight an entire textbook—eventually, nothing stands out.

This creates something called context rot—a documented phenomenon where AI performance degrades as input length increases, even on simple tasks. Too much information—irrelevant examples, conflicting guidance, tangential details—causes the model to lose signal in the noise.

It’s the same reason a junior accountant will copy-paste an entire interpretive guide into a memo instead of pulling the three relevant paragraphs. It’s the same reason a bad technical memo buries the conclusion under pages of background.

To get better outcomes, you don’t just add more data. You curate the smallest possible set of high-signal inputs.

The accountants who understand this instinctively—who know how to curate signal from noise—are going to be the ones who make AI actually useful.

How AI Actually Processes Information

Here's the technical reality most people don't understand:

LLMs activate concepts in parallel through their neural networks—just like expert accountants do. The concepts on the left (Contract Terms, Performance Obligations, Pricing, etc.) all fire simultaneously and interact statistically through the hidden layers in the middle.

But here’s the critical part: LLMs do not reason in steps by default. They activate concepts in parallel.

The five-step structure on the right? That’s the output format—how ASC 606 tells you to document your conclusion for GAAP compliance and audit trails.

In this way, ASC 606 is an output schema, not a thinking schema. It’s optimized for reporting and auditability, not for reasoning.

This is why naive prompts often fail. When you ask AI to “help with revenue recognition,” it often gives you generic, step-by-step guidance—because it’s following the structure of the documentation, not the structure of expert thinking.

Even reasoning models need to know:

• Which domain to reason in (technical accounting, not general business analysis)

• Which concepts to activate (ASC 606 specific, not generic revenue principles)

• What quality bar to meet (Big 4 audit standards, not internet blog posts)

Context engineering is how you aim that reasoning power at the right problems.

The 8-Step Framework I’ve Been Testing

So how do you actually apply this? How do you translate understanding parallel concept activation into something practical?

Over the past year, I’ve been experimenting with different approaches to context engineering for technical accounting. What I’ve landed on is an 8-step framework that seems to mirror how seasoned accountants actually think:

1. Concept Discovery → What core ASC 606 concepts are triggered?
2. Vocabulary Extraction → What specific terms and definitions matter?
3. Classification Debate → What are the competing interpretations? Where’s the ambiguity?
4. ASC Step-Mapping → How do these concepts map to the five-step model?
5. Step Interaction → How do multiple steps interact? (e.g., Step 2 affects Step 5)
6. Big 4 Stitching → What interpretive guidance from the firms applies?
7. References → What’s the authoritative source for each conclusion?
8. Conclusion/Risks/Disclosure → What’s the judgment call? What needs disclosure?

This framework isn’t teaching AI how to reason—it’s helping me specify what to reason about and what good looks like.

When I embed this framework into ChatGPT’s memory or a Claude Project, I’ve found the quality of analysis improves significantly.

Let me show you what I mean.

What This Looks Like in Practice

I uploaded a screenshot of a typical SaaS pricing page to ChatGPT—nothing more. Just a typical seat-based pricing model with different ‘good-better-best’ tiers, billing options, and AI credits.

The framework was embedded in ChatGPT’s memory. Here’s what happened:

The AI immediately identified the hidden complexity:

Most people would look at this and think “SaaS revenue, recognize over time, done.” But the AI caught something way more nuanced:

“Are AI credits that reset monthly variable consideration (Step 3), material rights (Step 2), or merely incidental benefits? This distinction matters—if credits are substantive, revenue must be constrained or allocated separately.”

Then it flagged one of the most hotly debated questions in SaaS accounting policy: Is usage-based pricing variable consideration under ASC 606, or options could be considered material rights?

This isn’t academic. The accounting treatment differs dramatically:

• Variable consideration → Estimated and recognized ratably with the appropriate constraint

• Optional purchase → Not part of the contract and therefore recognized as consumed, with any material right allocated to that option and recognized when exercised

It walked through all 8 steps systematically:

• Concept Discovery: Identified seat-based licensing, usage credits, tiered bundles, annual billing as triggers

• Vocabulary Extraction: Mapped “unlimited files” and “AI credits/month” to ASC 606 terms (stand-ready obligation, variable consideration, non-cash benefits)

• Classification Debate: Questioned whether Dev Mode is “merely incremental” or materially different (requiring separate performance obligations)

• Step Interaction: Noted that Step 2 conclusions (are credits distinct?) directly impact Step 4 (SSP allocation methodology)

• Big 4 Stitching: Anticipated audit focus—performance obligation memo, SSP methodology, credit breakage assumptions

• References: Cited ASC 606-10-25-14 (distinctness), 606-10-55-42 (material rights), 606-10-25-31 (stand-ready)

• Risks/Disclosure: Under-identifying performance obligations, Improper allocation of transaction price, Incorrect treatment of upgrades/modifications, Enterprise contracts bypassing standard rev rec logic

TL;DR (Controller-Level Take) “This looks like simple SaaS pricing — but from an ASC 606 perspective, seat differentiation + AI credits + enterprise customization create real complexity. The biggest risk isn’t timing — it’s performance obligation identification and allocation.

Without the framework:

• “This is SaaS revenue recognized over time”

• Generic five-step walkthrough

• Maybe mentions variable consideration

• No specific ASC citations

With the framework:

• Identifies the Step 2 vs. Step 3 classification debate

• Recognizes this as contested policy territory

• Cites specific ASC sections

• Anticipates audit focus areas

This is the difference between textbook analysis and expert reasoning.

The framework didn’t make the AI smarter. It made the AI think like a seasoned technical accountant who’s written dozens of these memos and knows where the judgment calls actually are.

Being an expert technical accountant is not about having perfect answers. It’s about asking the right questions. Expert level isn’t perfection—it’s knowing where the edges are.

That’s what the framework taught the AI to do. And that’s expert-level work.

How the Framework Came to Be

I didn’t set out to create a framework. I was preparing to teach a technical accounting research workshop for a revenue team that ranged from staff to director level.

The challenge: Reasoning models are incredibly good at nuance—but most people still get generic answers when they try to use AI for technical accounting. Why?

The gap wasn’t the model’s capability. The gap was context engineering.

When I use AI now, I barely think about prompts—the models “just get it.” But that’s because I’ve already done the work: ChatGPT has my 8-step framework in memory, Claude Projects have interpretive guidance pre-loaded, I ask domain-specific questions, and I can evaluate when output is right.

Beginners skip this setup and wonder why “help me with revenue recognition” returns textbook answers instead of expert analysis.

So I mapped out how I actually think when writing technical memos—not how ASC 606 tells me to document, but how I reason through problems. The insight: Beginners think sequentially (Step 1 → 2 → 3), but seasoned technical accountants think in parallel—activating multiple concepts simultaneously, just like AI does.

I used ChatGPT as a thinking partner to structure this into 8 steps. When embedded it into workflows, the research quality jumped immediately—not from better prompts, but from better context. It was having domain expertise, asking good questions, and iterating rapidly until the framework matched how I actually think - and using AI to externalize my expert thinking, not to replace it.

The framework doesn’t teach AI how to reason. It teaches you how to set up persistent context so AI reasons like a technical accountant by default.

The Memory Breakthrough

I recently sat down with Devon Coombs to compare the AI tools we actually rely on day-to-day. The insight? We’re building places where context can accumulate.

This is where persistent memory becomes the game-changer.

ChatGPT has had cross-conversation memory since early 2024—almost two years of personalization. If you’ve noticed ChatGPT “just getting you” over time, that’s why. It remembers your preferences, projects, and thinking patterns across separate chats. The 8-step framework lives in its memory—so every conversation starts with that foundation already loaded. Context engineering on autopilot.

Claude added persistent memory in fall 2025. If you’re a long-time Claude user who suddenly noticed it started remembering your work patterns and preferences, that’s the shift. It excels at deep reasoning and technical research, now with context that persists across conversations. Within a single chat, it still holds the most context (up to 200K tokens), making it powerful for complex analysis.

Gemini launched memory in August 2025, with massive context windows (1-2M tokens) and multimodal capabilities. The newest to the memory game, but with unmatched breadth for processing large amounts of diverse content.

What this means: Memory isn’t just convenience—it’s compound expertise. Every conversation builds on the last. The framework you embed once becomes the default thinking pattern. This is why some tools start feeling “smarter” over time—they’re not getting smarter, they’re getting to know you.

🎤 Devon and I go deeper on how we actually use these tools—and why memory is the unlock—in our latest podcast: “The AI Tools We Actually Use in 2026”.

You’re Right on Time

The reasoning models are getting better. The tools will keep changing. But the underlying skill—context engineering—doesn’t expire.

Reasoning models can think deeply. Your job is to tell them what to think about, where to focus, and what good looks like.

Understanding how to specify domain, set quality standards, and curate context—these are the skills that make you valuable regardless of which model is trending.

You’re not learning ChatGPT. You’re learning how to interface between expert knowledge and AI reasoning.

That skill compounds.

If you’ve been feeling behind, or overwhelmed, or like you “should” understand AI better by now—I want you to know: You’re not late. You’re right on time.

The skill that matters most—you already have it. Now we’re just learning to use it in a new environment.

What’s Next

If you want to explore these ideas further, I’m hosting a few upcoming sessions:

• Friday, Jan 30 9am pacific: AI Reporting Knowledge Share (Virtual - Gaapsavvy community members only - Register here)

• Tuesday, Feb 25 2:30-6:30: AI Finance Lab with Coterie CFO <> Gaapsavvy collab - SF at PwC (50 CFO/CAO teams, hands-on AI play time + sponsor demos) - (In person - apply to Join here)

And I’m working on something more comprehensive.

Last year, I started collecting interest for an AI Mastermind cohort. Thank you to everyone who signed up—I haven’t forgotten you, and I appreciate your patience.

Since then, I’ve been collaborating with Devon (my podcast co-host and former Google Cloud Marketplace Controller) on building a program that combines hands-on context engineering, workflow automation, and strategic AI fluency—designed specifically for technical accountants and finance leaders.

We’re finalizing details now and will share more in February. If you’re on the original waitlist, you’ll be the first to know.

Thanks for reading. If you’ve been experimenting with AI—whether it worked or failed—I’d love to hear what you’re learning. Just hit reply.

Angela

Disclaimer: This newsletter is for educational purposes only and based on lived field experience. Please consult your audit teams and internal controls before applying anything directly.

Hey there 👋,

A month ago, on Sept 12, 2025 - the EU Data Act went into effect.

This is a law passed by the European Union meant to give users more power to access and move their data—yet it sparked unintended consequences and some real anxiety in the accounting world.

Last Friday, 120+ accounting professionals from leading tech companies got on a call to talk about what they’re actually doing—and more importantly, how moving together through massive legal ambiguity might help shape how courts interpret this law.

Here’s what I learned: The industry is making a coordinated multi-billion dollar bet on a legal interpretation that won’t be validated until someone gets sued. Auditors are 23 percentage points behind legal teams in reaching conclusions. And next quarter’s reporting is going to reveal who didn’t get the memo.

This wasn’t compliance theater. This was 60 companies revealing their evolving positions, their real concerns, and their actual strategies—complete with live polling data showing exactly how divided (and how aligned) everyone actually is.

This is definitely one of those times where you want to stay in the pack.

The good news is—you’re not alone.

Let’s dive in.

💡 Quick benchmark poll — are you in or out of scope? Take the short survey

This community and newsletter is brought to you for free by Klarity.ai.

Powering always-On kAIzen, helping accountants bend the cost curve with AI. Join their upcoming Oct 22 AI Workshop or Dec 3rd HH in Palo Alto. Thank you for supporting the Gaapsavvy community!

Interested in sponsoring this newsletter? Message media@gaapsavvy.com

Subscribe now

🚨 Why Accountants Care: Save the RPO

The EU Data Act isn’t just a data regulation. Chapter VI Article 25 creeps into commercial contracts regulation because it gives customers the right to switch data processing providers with just two months’ notice. And it applies to you if you’re providing IaaS, PaaS, or SaaS services to EU customers—even if you’re a US company with no EU presence. (DLI Piper 2025)

In the accounting world, under ASC 606, if customers have the option to walk away easily, from a contract - it might be considered a ‘termination for convenience’.

That means that three-year contract you just signed, which showed three years of future revenue allocated to the “remaining performance obligation” aka ‘RPO’ - might only show as a two-month contract for reporting purposes in your financial statements under the accounting rules.

The nightmare scenario:

• You sign a $3M, three-year SaaS deal

• You report $3M in RPO to investors

• The Data Act says customer can terminate with 2 months’ notice

• Under ASC 606, your enforceable contract is now effectively 2 months

• Your RPO drops from $3M to $500K 😱

Multiply that across your entire book of business. Now imagine explaining that to your board.

But here’s the twist: There’s a legal argument that you can still charge customers the full remaining contract value even if they terminate early. The question is whether that’s a “proportionate” termination penalty under the Act or whether it’s punitive and unenforceable.

Based on community polling - 53% of companies are betting they can still collect. 37% aren’t sure yet. 10% think they can’t without explicit contract language.

Let’s break down the factors at play.

⚖️ Question 1: Is Your Data Processing Service Actually Legally In Scope?

Let’s start with the threshold question: Does the Act even apply to you?

The Act covers “data processing services” but deliberately left that term vague. When the Act was being written, a senior cabinet member of the commissioner who championed the data act was asked to clarify the meaning of “all data generated during use of the device” and he responded:

“That’s not my concern. This is for the courts to decide.”

Translation: Everyone is guessing. No one has been sued, this hasn’t gone through courts. There is no precedence.

Poll Results: Has your internal legal team concluded whether you are in scope of the EU Data Act?

A massive shift. When polling the community two weeks earlier, 64% were undecided. Legal teams are only now slowing working their way to conclusions—20 months after was written into law, and one month after the effective date.

How is legal concluding on whether data is in or out of scope?

The Emerging Pattern so far …

✅ Multi-tenant SaaS → In scope
✅ Hybrid (cloud console + on-prem agent) → In scope sometimes
❓ Single-tenant SaaS → Gray area (customization arguments might apply)
❌ Pure on-prem → Out of scope … most of the time

Examples of interpretations in ambiguity:

“Legal is pretty much like, for the SaaS piece, we are under the scope. They even said on-prem shouldn’t be, but they are not even 100% sure it’s not part of the scope.”

“Our legal position is not applicable to on-prem, but it’s applicable to SaaS.”

“Our legal team has not concluded on a position yet, but they were considering whether we were not in scope, given that the data we’re collecting is ancillary... and customers have the ability to port their data and export it.”

Only 7% of respondents concluded they’re out of scope. This exceptionally low percentage suggests the Act’s broad language around “data processing services” is capturing nearly everyone.

At the time of polling, only 32%, or about one-third have definitively used external counsel, suggesting many companies are either still in process or relying primarily on internal legal opinions for this unprecedented legislation.

External Counsel Correlation: Companies that used external counsel are more likely to have reached conclusions (14 in-scope vs. 4 not concluded). External legal expertise is appearing to drive consensus - and might be the hook that gets the audit world comfortable.

💰 Question 2: What’s a “Proportionate” Termination Penalty?

This is where the rubber meets the road. Can you charge customers the full remaining contract value if they terminate early under the Data Act? If so, this would be considered ‘substantive termination penalty’, the term of the contract stays the stated term, and RPO stays intact. (KPMG Question B140)

The “Proportionality” Legal Gamble:

The Act states termination penalties must be “proportionate” but doesn’t define the term. Two week prior, one large SaaS company shared that in legal discussions with the EU Task force, a termination penalty equaling the full remaining contract value could be considered acceptable as proportionate to the consequences.

Today - the 53% majority is making a business case: multi-year deals with upfront discounting justify full contract value collection.

Poll: Are you considering that fees are due in full upon early termination of the contract?

Key Distinction: The EU Data act makes a clear distinction between Termination penalties (consequence of breaking contract) vs. switching fees (barrier to competition). Whereas switching fees must be removed from contracts by January 2027, ‘proportionate termination penalties’ continue to be allowed. (EU Data Act paragraph 89)

Companies argue they’re the former, not the latter.

Here’s what’s being said:

“All fees are due and payable through the end of contract until a judge says otherwise. That’s where we’re landing.”

“We’re adopting the interpretation that’s most favorable to us... It works the same way as why we would not want to provide termination for convenience generally, given that we’re selling multi-year deals at a competitive price with upfront discounting.”

And again, there is no legal precedence today to tell us otherwise. Until someone gets sued under the EU Data Act, and it makes it through the courts - no one really knows.

📝 Question 3: Should You Update Contract Language?

Okay, you’ve decided you’re in scope. You’ve decided remainder-of-contract is proportionate. Now what?

Do you update contracts? Which ones? What language?

Poll: Are you making changes to contract terms?

The dominant strategy is clear: don’t poke the bear.

55% aren’t making changes yet, avoiding the risk of opening negotiations with existing customers. Any contract term updates are focused on new contracts - with only 5% attempting to amend existing agreements.

This approach is supported by EU Commission FAQ 42b, which suggests the Act may only apply prospectively (to new contracts), not to existing agreements. However, there’s debate about whether this applies only to data-related clauses or extends to commercial obligations.

“Legal is not changing the MSA yet, and we are standing behind the terms in our contracts that state that obligations are non-cancellable and nonrefundable, but adding language go forward.”

Expected contract term changes to protect the substantive termination penalty determination consisted of subtle wording changes that acknowledge the EU data act like “this termination fee represents a reasonable estimate of damages”’ or clarification that the penalty is not a switching fee.

Collectability Concern: Even if still legally enforceable, should you increase bad debt reserves? No historical data exists yet to evaluate this - yet.

📊 Question 4: What Should You Do for your Quarter Financials?

Here’s where legal theory becomes financial reporting reality.

And here’s the scary part: 60% of auditors haven’t even started discussions yet.

Poll: Has your auditor provided perspective?

Compare that to legal teams:

• 60% of legal teams have concluded

• Only 37% of auditors have engaged

That’s a 23-percentage-point gap. Auditors are waiting for the legal community to conclude.

And rightly so.

The pattern: Auditors want legal representation letters to support RPO treatment. They’re not making independent determinations—they’re validating legal positions. In some cases, there are even requiring external counsel to weigh in.

One company revealed what their Big Four Partners auditor actually said:

“Their conclusion will be a combination of legal opinion plus benchmarking with what other companies are doing.”

Translation: The 60% who haven’t engaged auditors will follow what the 40% early movers decide. This creates self-reinforcing consensus.

🎯 The Bottom Line: This Is Risk Assessment, Not Revenue Recognition (Yet)

Here’s what I really think after analyzing all this data:

The EU Data Act might be more of an ASC 450 (Contingencies) issue than an ASC 606 (Revenue Recognition) issue.

At the end of the day, determining whether a contract exists under ASC 606 depends on legal enforceability. And confidence in legal enforceability really comes from legal precedent - something no one has.

So before chopping off your RPO, pause and ask yourself: Is there enough evidence to say it’s probable our contracts are no longer legally enforceable?

I don’t think we have that data today.

What you probably need:

• Legal representation letters supporting your RPO treatment

• Risk disclosure language (not footnote adjustments)

• Monitoring plan for termination requests over the next 2-4 quarters

What you probably don’t need (yet):

• Massive RPO write-downs

• Panicked contract amendments

• Revenue policy changes

📊 Help Us Build Better Benchmarking Data

The polling data in this newsletter came from 60 companies in a live forum. But auditors explicitly said they need “legal opinion plus benchmarking with what other companies are doing.”

We need more data points.

I’m running a broader survey to capture industry positions across 200+ companies. Your anonymous responses will:

• Provide the benchmarking data auditors are requesting

• Help you see where your positions sit relative to peers

• Inform follow-up analysis as this situation evolves

TAKE THE 5-MINUTE SURVEY

Survey closes October 25. Results will be published early November.

📅 Upcoming Events & Community Sessions

• Oct 20-30th (times various): Numeric First AI Accounting 2 week sprint with me and Sowmya as guest lecturers (Register here - almost full)

• Oct 22 9am PT: Zuora Podcast: Finance Leaders Unfiltered (Register here)

• Oct 22 10am PT: Klarity AI Workshop: Be 15x more productive (Register here)

• Dec 3 5:30 PT: Klarity Happy Hour in Palo Alto: An evening with peers focused on operational excellence, sharing how leading teams are driving AI-enabled cost ratios, and making their orgs AI-Native over bites & drinks. (Join Waitlist here)

  Want to list your event here and support this newsletter? Message media@gaapsavvy.com

Thanks for being part of this community. Hit reply if you’re dealing with this too - I’d love to hear your approach.

Something I missed? Or have an additional resources? Please let us know and contribute to the collective wisdom. This piece is an output of the generosity of knowledge sharing on this fast evolving topic.

Oh - and don’t forget to check out the podcast and Devon’s newsletter!

Subscribe now

Disclaimer

The information shared in this newsletter comes from real lived experiences of our community accounting professionals - and is intended for learning purposes only. Polling data reveal industry “leans” in an “it depends” world. Every company’s situation is unique - always check with your lawyers, auditors and accounting team before implementing new approaches. Use these insights as starting points for your own research and discussions.

This edition of Community Wisdom is a little different — it’s a rapid-share recap from last week’s Shareforum so everyone can stay aligned on where practice is heading.

The headline: The EU Data Act could materially affect how companies present RPO if it’s interpreted as a statutory termination for convenience. That discussion alone could shape Q3 disclosures and audit positions across the industry.

🚨If you’d like to join the EU Data Act peer working session (Oct 10 @ 10 a.m. PT) — open only to industry accountant community members — reply here or message me to be added. That smaller group will compare legal conclusions, auditor views, and draft disclosure language ahead of quarter close.

I’ll continue with deeper dives over the next few weeks — each will focus on one of these topics (EU Data Act, marketplace treatment, FX, etc.) with full polling data and memo examples once peer discussions wrap up.

As always, I don’t distribute recordings so these sessions can stay candid, but this recap captures the highlights — what your peers are debating, where practices are diverging, and what’s next as we approach filings.

Best,
Angela

This community and newsletter is brought to you for free by Klarity.ai. AI for Finance Transformation, helping accountants bend the G&A curve with AI-powered automation for process documentation and contract review.

Check out what’s new in the Klarity Architect here! 🎉

Sept 26, 2025 Shareforum Topic Recap

Link to Slides

EU Data Act — Rev Rec Implications

What’s the issue

The EU Data Act (effective Sept 12, 2025) requires cloud providers to let customers terminate and port data within two months.

Does the Act’s right for EU customers to terminate and port data (within 2 months) create a de-facto termination for convenience (TFC) that shortens contract term/RPO, or can companies enforce proportionate termination penalties (distinct from switching fees, which phase out by 2027)?

Experiences shared

• Legal position/memos still in progress and diverse on if SaaS is “in or out of scope” of the EU Data act; interpretation varies by country and firm. Scoping differences could be related to the type of data, type of company (i.e. not only hyperscaler), or intent of act being data portability, not financial.

• Audit firms have differing conclusions but also depend on legal enforceability: some say this will definitely impact contract lengths and RPO tails, while others say the legal community is still very split on if SaaS is in scope.

• Contracts Terms “ Termination Penalties”: Many plan to add clauses making full remaining contract value payable upon early termination. This may be permissible under the act - pending confirmation (Discussions with EU taskforce to be confirmed)

• Switching fees: Must be eliminated by Jan 2027; however, these differ from “Termination penalties” which are still allowed to the extent that they represent loss to the vendor. Unclear if the proportionality of penalties cited in many accounting guides are relevant (10% cited by PwC/KPMG, though some prefer 30–50%).

• Polling Results show that as of 9/26/205 show that both legal and audit conclusions are still very much unsettled - leaving upcoming quarterly reporting at risk of inconsistent reporting among industry peers.

  

  

Take aways: Regroup Peer huddle Friday October 10th to align, and move consistently by consolidating learnings from internal legal counsel positions, work to align auditor’s understanding of industry view, and confirm “termination penalty” acceptability.

NetSuite ARM & RevPro: FX + Semi-annual Billing

What’s the issue

If you have a foreign currency SaaS revenue contract, with multiple billing installments, how do you handle FX differences between Revenue Contract recorded at the inception FX rate and the invoice recorded at the spot rate as billed. Should differences flow through revenue, FX G/L, or manual true-ups?

Experiences shared

• Two approaches were discussed: (1) book FX changes to revenue per ASC 606/IFRS 15 interpretations (KPMG/Deloitte examples), or (2) isolate in FX G/L to keep revenue cleaner.

• Netsuite ARM: configurable to route to record the difference to Revenue or FX Gain Loss “G/L”; Netsuite help content supports revenue remeasurement; multi-currency consolidation chains (GBP→EUR→USD) add translation noise.

• RevPro: early renewals/credit memos at new rates leave residual FX in RC rollforwards; product team suggests a setting to tie credits to the original invoice rate (doesn’t cover all ad-hoc credits).

• Audit posture: “No ERP does FX right”—materiality, documentation in understanding how your system records this - and possibly the periodic catch-ups are key.

Resources Shared: Deloitte FX Guide, Deloitte guide stating FX is not VC, Zuora Knowledge Center link on how Zuora Billing manages FX for AR related Transactions. This link will also guide you to setup the FX management for proration credit memo.

Cloud Marketplace Cutoff (AWS & Others)

What’s the issue?
If an End User accepts a private offer at 11:59 PM on Sept 30th, but the Marketplace posts invoice on the End User’s portal at 12:01 AM Oct 1st, does AR exist at acceptance or at platform billing?

Experiences shared

• Consensus: acceptance creates the unconditional right to consideration; platform posting is administrative (PwC “perfunctory billing” concept).

• Practice: generate internal/dummy invoices for cutoff; monitor post-close credits and reserve if patterns emerge; some exploring channel/DSR models to simplify.

• Poll: ~2/3 book at acceptance; ~1/3 wait for platform timestamp. Most companies record AR at contract acceptance and treat marketplace timing as admin—supported by controls (timestamps, dummy invoices, post-close credit review).

GCP Marketplace Resellers — Agent or Customer?

What’s the issue”?

Around 2024, Google Cloud Platform “GCP, changed their marketplace configurations to allow vendors to set a gross price and an explicit reseller margin in a four party transaction. This small structural change triggers an reassessment for independent software vendors when determining who is their Customer? Is the Reseller the Customer, or is the End user the Customer?

Experiences shared

• Intent: GCP changes were largely made to incentivize reseller participation on GCP and bolster principal positioning for resellers.

• SaaS pattern: Typically for all SaaS products, the vendor undoubtable controls hosting, delivery, and support overtime. This makes the end user the software vendor’s customer - and many gross up and record reseller margins as SG&A/commission-like expense.

• Support delivery nuance: more debate when resellers handle delivery/Level-1 support.

• Practice split: some gross (margin visible), others net for consistency; auditors focus on who controls the service, not what a portal field says.

• Poll: 55% treat reseller as agent (end user is customer); 45% treat reseller as customer (net)

Takeaway: Default toward end user as a customer in SaaS. Conclusions remain fact-specific—document control, pricing visibility, and roles.

AI Contract Reviews —

Question: How far have teams moved from manual review to AI-assisted contract analysis, and how much human oversight remains?

Experiences shared

• Adoption: ~40% piloting/using; ~60% not yet using.

• Tools: Klarity was the most cited as AI Deal Review Software being used; many others are building their own solutions in-house (on top of OpenAI/Claude/etc).

• Use cases: first-pass screening, clause extraction, risk flags; no full automation—human validation is standard.

• Barriers: audit defensibility, controls, and accuracy benchmarking.

Takeaway: AI is a speed assist in deal reviews, not a replacement—pilots are growing, but at least partial human review should be expected.

Term-Based License % Split Benchmarking

What’s the issue

For Term license SSP, what is your allocation split between license vs PCS amid scarce observable data and differing audit preferences?

Experiences shared

• Starting point: classic 80/20 (license/PCS).

• Alternatives: 50/50 gaining acceptance (esp. small/acquired products or strong renewals 80–90%+); expected term modeling from Deloitte vs cost/benchmark preference from EY/KPMG.

• Evidence tactics: renewal data; support cost/ticket metrics; R&D vs support ratios; external price lists (e.g., Oracle/Microsoft).

• Poll: 80/20 continues to be the majority; 50/50 growing (more common with Deloitte factoring the expected term; EY may accept with support - although they will not lead with this approach).

Takeaway: Both 80/20 and 50/50 can work—choice hinges on renewal stickiness, cost evidence, and sometimes even your auditor’s preference.

What’s next
Over the next few weeks, I’ll back to publishing deeper dives on some of these topics — starting with the EU Data Act and Usage Based Selling models.

Those follow-up posts will include the detailed polling data, peer examples, and sample memo frameworks that came out of the smaller working sessions. If you’d like to contribute or preview drafts, reply here or message me directly — the goal is to capture where real-world practice is heading before it hits the formal guidance.

Interested in sponsoring this community? We’d love to have your support! Send inquiries to media@gaapsavvy.com.

Welcome back to Field Notes — I've been quietly working on something new, and I'm excited to finally share it.

This issue tackles a topic that's come up again and again in Gaapsavvy conversations - how to account for revenue and fees when selling through cloud marketplaces like AWS, GCP, and Azure.

From the outside, it might look like outsourcing billing and collections would make things easier — but as most of us know by now, it's anything but. Principal vs. agent decisions, fee classification, reporting visibility gaps… it's an expensive gray zone. And with cloud infrastructure spending growing 25% year-over-year, more finance teams are wrestling with these decisions every quarter.

This also marks the launch of the new Gaapsavvy Podcast, co-hosted with Devon Coombs, former Google Cloud Marketplace Controller. Our first episode dives into marketplace accounting — including the conversations that never make it into the memo. (Linked at the end.)

Let's get into it.

This community and newsletter is brought to you for free by Klarity.ai. AI for Finance Transformation, helping accountants bend the G&A curve with AI-powered automation for process documentation and contract review.

Check out what’s new in the Klarity Architect here! 🎉

The Stakes Are Higher Than You Think

Cloud marketplace sales are exploding. An increasing share of SaaS revenue now flows through AWS, GCP, and Azure—the very platforms these companies are built on. But while engineering teams love the streamlined procurement, finance teams are discovering a mess of accounting complications.

The problem? These platforms do far more than process payments. They handle sales enablement, marketing exposure, contracting, billing, and collections.

This blended role has created a fundamental question that's dividing the accounting community. Here are some recent questions discussed in the community:

Q: Where Do Marketplace Fees Belong on the Income Statement - Sales & Marketing (Opex) or Cost of Sales (Margin)?

Your answer determines whether these fees hit your gross margin or stay below the line. And with marketplace fees typically running 3-8% of revenue, this decision could have material P&L impact.

This leads to a core accounting question:

• If you view these fees like commissions, they may fall under ASC 340 as a Cost to Obtain a Contract, typically classified as Sales & Marketing (Opex).

• If you analogize them to payment processing fees, they’re more often treated as a Cost of Sales (COS) — impacting margin directly.

What's Actually Happening

At a community share forum in January of 2024 with public and private SaaS companies audited by Big 4 firms, we ran a series of community polls to better understand how accounting teams are handling Cloud Provider Marketplace fees.

The responses showed just how divided — and judgment-heavy — this space still is:

What this means

• There is no consensus and vast diversity in practice. With a nearly perfect 50/50 split on both P&L classification (58% S&M to 42% COS) and capitalization (51% Capitalize to 49% Expense), marketplace fees accounting has become the "wild west" of revenue. This inconsistency makes comparability arguably meaningless—companies with identical economics can report vastly different gross margins purely due to accounting choices.

• There's a Clear Preference Gap When asked for industry preference 69% of accountants responded that would prefer to classify these fees as Sales & Marketing. The data reveals a telling story: 58% currently classify marketplace fees in Sales & Marketing, but 69% want them there. This +11 percentage point gap suggests many companies feel pressured to use Cost of Sales classification despite preferring Sales & Marketing treatment.

• Material P&L Impact Moving fees from Cost of Sales to Sales & Marketing shifts expenses "above the line," directly improving reported gross margins. Combined with the capitalization decision, these choices can significantly impact how investors and analysts evaluate company performance.

Bottom Line: The marketplace fee accounting landscape is ripe for standard-setting intervention. With strong industry support for standardization and clear preference for Sales & Marketing treatment, revenue leaders have both the opportunity and backing to advocate for consistent guidance—particularly for cloud marketplace fees. It reflects how many teams see these platforms — not just as infrastructure, but as distribution partners with a sales function.

Q: Do you create dummy invoices to operationalize marketplace accounting for AR and Collections?

The Core Problem: Operational Nightmare

Software vendors typically conclude they're the principal in marketplace sales (recognizing revenue gross), which means they must maintain accounts receivable balances and track collections. But cloud marketplaces often conclude the end customer is their customer, sharing minimal details with software vendors about contracting, credit checks, billing, collections, payment processing.

What’s really happening: The Workaround

"We're not running full collections, but we still need to book AR balances and bad debt reserves. It's an ugly back-and-forth with the marketplace (tickets) to understand what's happening at each customer level."

• Most Companies Resort to "Dummy" Invoices. 63% create dummy invoices for marketplace transactions—a telling sign that existing marketplace processes don't align with standard accounting workflows. Companies are essentially creating artificial paper trails to make marketplace transactions fit into their financial systems.

• AR Classification: Although “real billing” is done by the Marketplace, most companies classify their “dummy invoices” as Trade AR. This was by far the most common answer, with three-quarters of companies booking marketplace balances here. A smaller group uses unbilled AR, while contract assets were almost non-existent. This aligns with technical guidance that SaaS marketplace arrangements rarely meet the contract asset definition.

• Invoice Level Customer vs. Sales Order Split: Practices split nearly evenly between invoicing at the sales order level and at the customer level, with a smaller portion treating the marketplace provider itself as the customer. This reflects ERP system design and the granularity of marketplace reporting more than differences in GAAP interpretation.

Bottom Line: The prevalence of dummy invoices (63%) highlights a fundamental disconnect between how marketplaces operate and how finance teams need to account for the business. The near-universal use of Trade AR (78%) suggests companies are forcing marketplace transactions into traditional receivables frameworks rather than developing marketplace-specific accounting approaches.

The real question is: Are dummy invoices a necessary workaround or a sign that we need better integration between marketplace platforms and ERP systems? With 63% of companies using this approach, there's clearly a systematic gap between marketplace operations and financial reporting requirements.

The data suggests this is less about accounting preference and more about operational necessity—companies are creating these artificial processes because marketplaces don't provide the financial infrastructure that finance teams require.

🎧 Want to go deeper?

Devon Coombs (ex Google Cloud Marketplace Controller) and I break all the nuance of marketplace accounting in our the very first episode of the Gaapsavvy Podcast.

We covered topics I hadn’t even thought about before 🤯

— now live!

Episode link:

Length: 1:03 minutes

Time-stamped highlights

• 00:00 Intro: Why you should care about Marketplace accounting

• 08:20 Software Vendor vs Cloud Marketplace Owner View

• 17:54 Marketplace fee Classification - Sales and Marketing or Cost of Revenue?

• 29:39 Community Polling: Classification Diversity (2021 vs. 2024)

• 32:15 Partner and End User Relationships: Marketing Benefits and Cost Offsets

• 37:45 The Real Strategy: Driving Cloud Consumption

• 44:50 Does the real strategy reveal a lean to Sales and Marketing classification?

• 51:10 Marketplace’s ability to connect sales and cost data

• 54:33 Will understanding Cloud Cost change our usage rev rec conclusions?

• 01:03 What's next - a deep dive into usage/consumption accounting 🥳

What’s Next

The next podcast episode will be on Usage & Consumption Technical Accounting.

And yes - this month we had the Klarity AI Summit in NYC. There is so much to cover in the world of AI! Stay tuned.

Upcoming Events:

• Friday June 26: Next Gaapsavvy QTC Shareforum for industry accountant community members

Thanks again for being part of this community. Hit reply if something in here spark a thought, a question, or even a “we’re dealing with this too.” I’d love to hear from you.

A quick note: You're getting this because you’ve expressed interest in access to community content or joined a related Gaapsavvy program. While I have limited shareforum participation to practicing industry accountants only for now, I wanted start sharing these insights with everyone who's shown interest in what we're building.

Not your jam? No hard feelings. Easy unsubscribe below.

Disclaimer

The information shared in this newsletter comes from real lived experiences our community accounting professionals - and is intended for learning purposes only. Polling data reveal industry “leans” in an “it depends” world. Every company's situation is unique - always checking with your auditors and accounting team before implementing new approaches. Use these insights as starting points for your own research and discussions.

Leave a comment

Welcome to the very first issue of the Gaapsavvy Newsletter Field Notes — an industry view of what's actually happening on the ground in SaaS accounting — what's working, what's broken, and what's next.

After years of running shareforums, I’ve long wanted to start a newsletter and just didn’t know where to start. But as they say, "never let perfect be the enemy of good" — it's better to just start.

At our last shareforum from Klarity HQ, we brought together 65+ accounting professionals from leading tech companies to talk about what’s really happening.

In my accounting career, I've often wondered "someone else must have this same question, I wonder what they are doing."

Turns out you’re right — you’re not alone.

Let’s dive in.

This community and newsletter is brought to you for free by Klarity. AI for Finance Transformation, helping accountants bend the G&A curve with AI-powered automation for process documentation and contract review. Thank you for supporting the Gaapsavvy community!

Check out what’s new in Klarity Architect on June 10th : Register here to learn how you can leverage AI in your process documentation and internal controls.

Subscribe now

Want to listen instead? Check out this AI generated audio overview in podcast form, generated by Google’s NotebookLM. Not perfect, but mind-blowingly good.

Quick Hits from the April Shareforum:

Who’s at the table this round: 65+ accounting professionals from leading tech companies. Company profiles: 73% private to 27% public companies - 88% audited by Big 4 auditors (indicating Series C+ maturity preparing for IPO).

Here are the questions we discussed in April:

• Partner Reseller revenue share model, how do you account for them? The gross vs. net debate is back in focus — possibly sparked by this this new publication. Reality check: even if you theoretically conclude "gross" treatment is appropriate, you can't record revenue for end-user pricing you don't actually know.

• Stripe Billing for Usage with NetSuite, what lessons pitfalls can you share? - Engineers love Stripe Billing, but accountants face manual workarounds for JE upload into NetSuite. Key insight: companies need SQL or Stripe Sigma skills just to extract data, and Stripe vs. Salesforce FX rounding decimal differences create persistent variances.

• AWS Marketplace tooling, what intermediary software have you found success with? Cloud marketplace selling creates RevOps visibility gaps and look to specialized tools like Clazar, Tackle, and Suger.

• Term License SSP allocation split benchmarking, what’s your % split? - Term license allocation ratio acceptability differ by audit firm - drifting from the classic 80% License/20% PCS split, to more heavily weight PCS. Compared to 2021, more companies are using a fixed term vs. variable term to arrive at estimated SSP (see Deloitte’s publication).

• Sales tax presentation, do you include tax on sales orders, or just invoices? - Most companies only show tax on invoices due to system limitations as tax engines integrate with billing not CPQ. International requirements sometimes exceptions often handled manually. Tax compliance penalties are generally treated as operating expenses rather than contra-revenue.

Focus Feature: Two Usage Questions from April

As more companies move to usage-based models, countless challenges emerge.

These two specific questions that came up in our April discussions...How do you make internally generated usage data auditable? And how do you calculate ARR when customers blow past minimum commits?

These challenges reflect a broader pattern - the industry keeps trying to force usage-based models into old frameworks that don’t quite fit.

Q: What have others done for audit evidence to support internally generated consumption-based billing data?

How do you get auditors comfortable with homegrown usage systems?

The Traditional vs. Digital Challenge

Traditional audit evidence doesn't work for digital usage data. Historically, auditors relied on external third-party evidence - shipping documents, customer confirmations sent directly by auditors.

In the digital world, "proof of delivery" is simply usage data generated internally by your homegrown product, where the system captures events based on instructions written in code.

"We built custom tracking and walked through the logic, but it still wasn't enough."

What's Actually Working

Based on our community polling, accounting teams need multiple types of audit evidence, not just one:

Real Examples from the Field:

• PwC approach: Created a "test audit account" where auditors signed up as customers to verify system accuracy. Similar approaches confirmed across Deloitte and KPMG.

• KPMG approach: Classic customer confirmations - auditors reach out to customers to validate usage data. While this creates a circular reference (customers confirming data from the system being audited), multiple firms still use this procedure.

• Hybrid approach: One team described combining event tracing with database snapshots and quarterly code reviews with their engineering team.

Bottom Line: Start with event tracing + screenshots as foundation. Layer in 2-3 additional evidence types. If you're going public, propose the "auditor test account" approach early - three firms confirmed this works. Audit scrutiny increases dramatically after the public company transition.

Q: For usage contracts with minimum commits, do you include usage overage fees in Annual Recurring Revenue (ARR)?

The Core Problem

Traditional ARR calculations fundamentally break down for usage-based models because ARR assumes recurring predictability that doesn't always exist in consumption models.

ARR is unaudited, non-GAAP, and lacks specific rules on what should be included or excluded. ARR is used by investors as a forward looking metric, with an assumption that ARR will is recognized smoothly as GAAP revenue in future periods.

Usage-based companies often find themselves forcing consumption data into subscription metrics that weren't built for this business model.

What's Actually Working

Snowflake is arguably the trend setting consumption company - and one senior team member shared: "We don't use ARR ourselves. We use net recurring revenue and how that's increasing on a customer and cohort basis because we're usage rather than ratable SaaS."

( Check out Snowflake’s Q12-26 Investor Report as an example)

This highlights a critical insight: companies with truly consumption-driven models may need entirely different metrics rather than trying to retrofit ARR calculations.

The community revealed several distinct approaches, each shaped by company maturity and usage predictability:

• The Conservative Exclusion Approach: Smaller companies often exclude all non-committed usage. "We keep track of them, but we don't include them as actual ARR due to our size—we don't want to get burned and have to reforecast."

• The "Burned Once, Cautious Twice" Method: Companies that experienced volatility adopt waiting periods. "We got burned and decided to give it first annual experience. Only after 4 quarters when we come up to some reasonable rate, we are adding this to ARR."

• The Quarterly Annualization Approach: Others take quarterly overage revenue and multiply by four, with caveats: "It helps to have history—if your overages are all over the map, then ARR times 4 just blows up when it goes down and blows up when it goes up, and investors get confused."

Key Insights:

1. Public companies are more conservative - 62% exclude non-committed usage vs. 51% for private companies

2. Usage volatility drives methodology choice - stable patterns enable more aggressive inclusion

3. The "4 quarters of history" rule is emerging as best practice for transitioning from exclusion to inclusion

4. Alternative metrics gaining traction - companies with heavy usage / consumption revenue exploring net recurring revenue growth

Bottom Line: If usage represents the majority of revenue, consider abandoning ARR entirely. Follow successful consumption companies' lead with net recurring revenue growth or customer cohort consumption trends. If you must use ARR for investor compatibility, exclude volatile overages until you have 4 quarters of predictable history. The goal isn't perfect ARR calculation—it's meaningful measurement of business trajectory.

What’s Next?

AI is eating our world. Coming off the Klarity SF AI Summit, I can't wait to dive deeper into sharing knowledge on how we’re using AI in our daily work. Quick share from me in crafting this newsletter using chatGPT, and Antropic’s Claude. Claude really blew my mind in how well it coded infographics and dug into insights.

More on AI in the next issue.

Upcoming events:

• June 10: Klarity Architect demo - AI for process documentation Sign up here

• June 13: Hands-on AI Masterclass Collab with Sowmya Ranganathan ex-OpenAI Controller & Founder at Lumera ( paid) Sign up here - and make sure to check out her super practical newsletter here!

• June 17: Deloitte Roundtable: Accounting Implications for AI companies (in person) Sign up here

• June 27: Next QTC shareforum for industry accountant community members

Thanks again for being part of this community. Hit reply if something in here sparked a thought, a question, or even a “we’re dealing with this too.” I’d love to hear from you.

A quick note: You're getting this because you’ve expressed interest in access to community content or joined a related Gaapsavvy program. While I have limited shareforum participation to practicing industry accountants only for now, I wanted to start sharing these insights with everyone who's shown interest in what we're building.

Not your jam? No hard feelings. Easy unsubscribe below.

Disclaimer

The information shared in this newsletter comes from real lived experiences our community of accounting professionals - and is intended for learning purposes only. Polling data reveal industry “leans” in an “it depends” world. Every company's situation is unique - always check with your auditors and accounting team before implementing new approaches. Use these insights as starting points for your own research and discussions.

Leave a comment

Welcome to Field Notes! An industry view of what's actually happening on the ground in accounting — what's working, what's broken, and what's next.

It's a mix of deep insights from Gaapsavvy shareforums, tools practitioners are actually using, and themes we'll unpack together over time.

Some issues dive deep on a single topic. Others sweep across industry trends. Either way, I'm giving it to you straight—the good, the challenging, and the 'nobody talks about this but everyone struggles with it.'

Who It's For

You're likely:

• An industry accountant tired of ivory tower guidance followed by an expensive "it depends"

• Someone exploring AI without time for another vague "future of finance" webinar

• Craving real examples and judgment calls from people who've lived it

Subscribe now

Why This Matters

These conversations are too valuable to keep contained. The collective wisdom that emerges when practitioners speak candidly deserves wider sharing—not because I have all the answers, but because we all benefit from real-world perspectives.

I founded Gaapsavvy to create 'open source accounting'—where professionals share learnings the way developers collaborate on code, building something better together.

With AI transforming our field faster than ever, learning in community is essential. My goals are simple:

• Make interpretations more consistent

• Align system requirements across companies

• Create a space to upskill and grow together

For years, my shareforums have gathered insights you couldn't buy with consulting dollars. This newsletter brings that knowledge to everyone without losing the nuance (or the honesty).

📬 First full issue coming soon — covering usage-based revenue in depth.

📣 Have a topic you'd like unpacked? Reply anytime.

Glad you're here,

- Angela