It’s been a minute since the last issue - and somehow it’s now July. Is anyone else feeling AI whiplash?

We opened June’s AI Shareforum — 150 practitioners, 85% Big 4 audited — the way I always do. With a practice poll:

Vibe check: Where are you on the AI journey?

💬 Still living in chat for a lot of it — 59% 📊 Excel & PowerPoint sidekick — 47% 📈 Vibing dashboards — 17% 😵‍💫 …okay, I’ve now made too many dashboards — 6% 🛠️ Built apps for real workflow use cases — 20% 🚀 Solutioned whole workflows end to end — 6% 🧹 I’ve overvibed — send help, I need to consolidate & govern — 2% 🤹 Honestly? A little bit of all of the above — 11%

Read as a sentence, one in five of us has built a real application. That isn't experimentation anymore — that is where internal controls kick in.

For a solid 28-minute stretch of our June AI Shareforum, members compared notes on what the Big 4 are actually telling clients about AI in controlled processes. All four firms came up. All four answers were materially different.

At first, it sounded like disagreement. The more I sat with it, the more I realized something else was happening.

The technology is moving faster than the shared language we need to govern it. Engineers, auditors, and controllers are often describing the same underlying ideas with completely different words.

I’ve become convinced that one of those new important words for us is harness design.

Let me show you what I mean.

This newsletter is brought to you for free by Right Rev:

Every Case Accounted For. AI-Powered Revenue Recognition. Simplify and automate complex revenue recognition, gain real-time insights, and ensure ASC 606 / IFRS 15 compliance – now with the Revi suite of AI tools. Request a demo.

What the four firms are saying

A quick caveat on how Gaapsavvy works: Shareforums start with one member's crowdsourced question — on the premise that one member's conversation stands in for hundreds of identical 1:1s happening across the industry between individuals at companies and firms. Members compare notes, reconcile differences, and bring a more informed perspective back to their auditor. No one can stay on top of all of this alone, we can be each other's eyes and ears. Here's what we heard:

PwC is the most aggressive. Members attending PwC’s AI conferences in SF and San Jose watched the firm present its proprietary platform, PwC One — a full platform posture where every agent is documented from day one: the testing sample, a lifetime accuracy threshold it must maintain, a review cadence for the life of the deployment, and a captured log of every step of every run. The pitch: the human stops re-performing the output and instead reviews the agent’s steps, leaning on the tested deployment. Partners are calling it deterministic AI agent deployment, and report that auditors of PwC’s consulting clients are satisfied with the level of documentation. (Said with affection: putting a language model through prescriptive steps makes it better behaved, not deterministic — the same way a strong close checklist never made your staff deterministic either. The honest claim is "we shrank the judgment zone and controlled it" — and that claim is both auditable and directionally right.)

Deloitte told one member — in a call the day before our session — that human-in-the-loop alone won’t be enough: expect continuous monitoring controls, operating outside the execution moment. First time she’d heard it. I suspect the first of many as teams really start to build.

EY pushed back on one public company’s use case — using AI to extract information from contracts and pre-fill a rev rec checklist. Their question: “How do you evidence that every contract term has been properly extracted, without 100% manual human re-performance?” Meanwhile, EY is telling clients it plans to deploy AI agents in its own audits next year. The chat wrote its own punchline: “yet the audit fees are not being decreased 🤷🏻.” Within sixty seconds, other EY clients in the room were comparing notes — and I offered that this might be exactly the place the community pushes together.

KPMG told a December financial reporting conference that it sees AI agents auditing clients in the future — “definitely more questions than answers.”

And above all four: the PCAOB has published observations, not standards. Staff spotlights and outreach summaries exist; the thing a national office can actually lean on does not. Which is why, per one member’s outreach, one of the largest companies in the world has sorted every AI use into assist, augment, automate — and banned the automate bucket outright for two years while it waits for the regulator to speak.

Here's the part that matters: the firms aren't contradicting each other.

Put the four positions side by side and they’re recognizably branches of one decision: how much reliance on the AI, proven how. Full human review with no reliance? That’s a management review control everyone already knows how to test. Reduced review? Then reliance with conditions — tested at deployment, proven accuracy, sustained validation.

Four institutions, translating the same underlying logic into four ad-hoc dialects, client by client, partner by partner. Why dialects instead of one language? Because the connective vocabulary for this entire space is younger than a busy season.

A Word that is Five Months Old

Earlier this year I kept hearing the word “harness engineering” and didn’t know what it was. It turns out the phrase was coined in February 2026 — five months ago — by Mitchell Hashimoto, co-founder of HashiCorp. Frontier labs like Anthropic and OpenAI have since published reference architectures around it. An entire emerging discipline, named five months ago.

So what is a harness?

Let’s start with the premise: a model, as a worker, is powerful but stateless and fallible. Every session starts with no memory, holds finite context, and drifts on long tasks. Most dangerously, it fails plausibly — when it’s wrong, it’s confidently, articulately wrong. None of this can be fixed by prompting harder. These are properties of the model as a worker, not the instructions.

A harness is everything you build around that worker so its work can be trusted anyway. Every piece of the harness is engineered because of one specific failure mode:

• Because sessions forget, the state lives in files, never in chat — a handoff document the next session reads first. The project files remember even though the worker doesn’t.

• Because instructions given in conversation decay, the rules are standing orders loaded at the start of every session, not things you said once and hope stuck.

• Because the model improvises under ambiguity, the gates fail closed — an unknown account, an entry that doesn’t balance, and the line stops loudly, instead of a plausible guess sailing through.

• Because no author can audit their own work — the whole reason preparer and reviewer were ever separated — review is done by fresh eyes that didn’t make the change, prompted to attack it, not confirm it.

• And because every caught failure is information, the harness ratchets: each incident becomes a new permanent check, tested to prove it can actually fire.

Now read that list again. Those engineering - defined failure modes look a lot like our “What Could Go Wrongs”.

Harness design is the discipline of making the system more reliable than the model inside it. It determines how much uncertainty a workflow can safely tolerate before a human must intervene. Prompt engineering tries to make one session behave well; harness design assumes any single session might behave badly — and makes that survivable by designing the environment around it.

It’s the difference between hiring carefully and having internal controls. We don’t build accounting around the assumption that people never make mistakes. Perhaps the interesting question is not whether a model hallucinates, it’s whether the harness designed around that model is strong enough to prevent, detect, and correct those mistakes before they become financial reporting issues.

That’s the harness. And that's why everyone giving governance guidance right now sounds like they're improvising: they are. The connective language of a new discipline is only five months old.

I watched it happen on my own screen

Over the July 4th weekend I forced myself to learn how to use Claude Code in the terminal - and used Anthropic’s newest model Fable to build a data pipeline for this community. I stated my goals, Fable interviewed me and produced a roadmap - the pattern assembled itself out of necessity:

• Fable (the brain & mission control): the expensive judgment model planning the work, writing specs and performing adversarial reviews

• Sonnet (the builder): the cheaper execution model building from Fable’s specs

• Me (the human) - the only seat that never delegates — ruling on anything irreversible.

Sessions ended; the HANDOFF.md file carried the state. A verification battery ran after every change, and when it went red, the work stopped and waited for me. And when the builder’s own checks said clean on something sensitive, a fresh-eyed reviewer agent that hadn’t written the code found dozens of problems the author’s checks had missed. Three review rounds before one came back empty. That rule is permanent now. That’s the ratchet.

Fail-closed gate - (engineering: verification harness; audit: preventive control). Nothing merges until it's green — and green requires my ruling, not the model's guess. ( Sonnet in Claude Code)

Independent review - (engineering: adversarial evaluation; audit: preparer/reviewer separation). The math checks passed. The author’s checks said clean. Fresh eyes found it anyway. (Fable in Claude Cowork)

Persistent state (engineering: context handoff artifact; audit: the workpaper file). The session died. The system remembered in a new context window. An audit trail writes itself. (Sonnet in Claude Code - new context window)

Only afterward did I re-read Anthropic’s engineering post on harness design for long-running work and realized Claude Code is itself a harness. Their team, inspired by Generative Adversarial Networks, split the work between a generator and an evaluator, with concrete criteria for what 'good' looks like — the unlock for rich full-stack applications built over multi-hour autonomous sessions.

Our accounting instincts designed the same architecture for human workers decades before engineering had words for it: separate the doer from the checker, write it down, stop when it doesn't tie."

“Isn’t this just… what we already do?”

Every training, someone asks the honest question: aren’t controls over AI the same as controls over any manual process? A human staff accountant isn’t deterministic either — as one member put it in June, depending on the mood and the weather that day — we were never able to audit the reasoning in their brain - internal controls were how we made people-processes reliable. Preparer and reviewer. Sampling. Management review. The management review control was never a technology; it was a harness for people.

So: Yes. Same architecture. You’ve spent your career doing harness design, which is why this will come faster to you than to almost anyone.

But there are also some very real, very new risks (i.e WCGWs) that we are just starting to feel — and they deserve an honest answer, not just the comforting one.

The architecture transfers. The risk math doesn’t.

Your staff don’t produce confidently wrong answers a thousand times an hour; an agent can. Your staff don’t get their brains silently swapped by a vendor overnight; a model version can. And your staff have never handed you a beautifully written rationale that isn’t actually how they reached the answer — which AI models demonstrably can, and which is why a harness logs actions as evidence, never the model’s narration. Speed, scale, and a new kind of failure — that's what's actually new. Smaller than the panic, bigger than nothing.

The unit of measure that was always ours

The new word is also the fourth rung of a ladder we’ve been climbing in public:

From our context engineering conversation in January, to harness design of the whole environment the AI runs in, the unit we control keeps grows from a use-case to a whole system. Translate “whole system” into the scope of responsibility of the accountant - it’s the end-to-end process.

Quote to cash. Record to report. Procure to pay. Engineers rarely got to think at that altitude — they were scoped to an application or a feature, and accountants were the ones made to assess all the little pieces in between, stitched into one end-to-end flow. The shift doesn’t climb to somewhere new. It climbs to the unit of ownership accountants have been responsible for all along.

And per June’s capabilities poll: 61% of this community has already used Claude Code or Cowork. That means we’re in the fourth column— and mostly without the vocabulary. That’s exactly the gap.

The vocabulary is arriving

In June 2026, FEI’s Committee on Corporate Reporting put a first formal vocabulary in writing — the AI Framework: Internal Control Over Financial Reporting. It keeps your existing SOX program as the foundation, routes deterministic builds back to normal ITGCs, and names four control approaches for the probabilistic branch: human review designed by nature, timing, and extent; testing against known-input/known-output sets; a second independent model validating the first; and population-level analytics watching for drift. It is a starting point in a field moving faster than any framework can publish.

Read those four approaches as a builder and you'll recognize them instantly — engineers call them evals, golden sets, LLM-as-judge, observability. The accounting authors described the harness playbook, just using a different dialect:

One more term that’s worth mentioning from the FEI framework that I suspect we’ll hear a lot more about: Shadow Reliance.

It’s the human in the loop who still signs off but has stopped truly reviewing, because the output kept looking right. A review control on paper; unconditioned reliance in substance.

I can honestly say I didn't really understand this risk until I caught myself shadow-reviewing within one weekend of agent approvals: "Yes — allow bash." "Yes — allow edits every time." "Yes — don't ask again." …and finally:

By Sunday, decision fatigue had quietly retired my review to shadow reliance. It isn’t a character flaw — it’s what happens to any competent reviewer at machine speed.

Before your next auditor conversation

Five things, in order:

1. Run the routing question: deterministic or probabilistic? If AI built it and fixed code runs it — take the exit ramp. Normal ITGCs. Go run, be glad.

2. If probabilistic: is the AI part of the process, or is it the control? And what’s the risk if it’s wrong? These two questions place you on the map.

3. Decide the reliance question explicitly instead of drifting into it. “We rely / we don’t rely, and here’s the condition set” is a sentence your auditor can work with.

4. Audit yourself for shadow reliance before anyone else does. When did your review last actually catch something?

5. Walk in carrying the shared words — reliance, performance testing, sustained validation: forward this issue to your engagement team along with the FEI framework (totally worth the price) . The members who arrived with vocabulary report better conversations than the members who waited for their firm to improvise one.

If you’re in the 59% still living in chat: you’re not behind. You’re early — and this time the vocabulary is arriving before your build instead of after.

The frameworks are the profession’s law: necessary, authoritative, and by design, slow. The builders are moving weekly. What’s been missing is the layer in between — where one member’s auditor conversation becomes another member’s opening position, faster than any single firm can publish. That layer is what this community has been building all along. This issue is one piece of it; what you send back is the next.

July 24 — I'm sitting down with Jason Pikoos, one of the authors behind the FEI framework, to go deeper on exactly these questions: reliance vs. non-reliance, shadow reliance, and what human-in-the-loop actually means — anchored on real member cases. Join us here.

And hit reply. If you’ve had the auditor conversation — the one that went well or the one that went sideways — send the exact words that were used.

That’s how the next layer gets built.

And we get to build it together.

-Angela

What’s coming up:

Friday, Jul 24, 10am PT — AI Governance & Internal Controls, with Jason Pikoos (Modern Finance @ Meta · COSO board · FEI framework co-author). Register HERE. Know an advisor or auditor wrestling with this? Forward this along.

Aug 12 — AI in Finance Lab (Gaapsavvy × Coterie CFO, at Deloitte SF) — half-day hands-on workshop; laptop required, in-house practitioners only, in person capped at 60. Register/Apply HERE

From real practitioners, for learning purposes only. Polling data shows industry leans, not final positions — every company’s facts are different. Always work with your auditors and internal controls team before implementing anything new.

Hey there 👋

If you’re new — welcome. Many of you found Gaapsavvy because you registered for the April 17 session with Adam Dix from Anthropic’s finance team. I’m glad you’re here, because what I want to write about today is something I’ve been carrying for eight years and didn’t have the proof for until last month.

This room came together because of one question that kept coming up at our March shareforum — over and over, in the chat, in the polls, after the session: “How is anyone actually using Claude Code and Cowork in a real finance workflow?”

On April 17, we ran a session. Adam would show what his team had built with Claude. Our community would ask questions. 1,876 registered. 1,312 showed up on a Friday morning, from roughly 500 enterprise tech companies. 81% were in-house finance and accounting, and of those 77% audited by the Big 4.

Adam generously shared how he started experimenting, accumulated context in projects, asked Claude where to start, working ‘side by side’ with Claude Code, and built things that actually worked. He shared the whole journey — including where he got stuck, and the parts that surprised him.

Live attendees submitted 160 questions, answered three live polls, and produced — what I can only describe as a practitioner-generated product roadmap for production AI in enterprise accounting.

That’s not a webinar. That’s an industry showing up.

This is the article where I finally say what I think we built. And what I think we should do with this moment.

Let’s dive in.

This newsletter is generously sponsored by Zuora, the leading Quote to Cash Platform for Growth.

The problem: A one way street with no feedback loop

Eight years ago I sketched a diagram I never published. It’s still on my desk.

At the top: standard setters who write the rules. The Big 4 who interpret and audit. The software vendors who build. The firms and vendors partner across the middle — go-to-market motions, advisory engagements, audit tech.

At the bottom: in-house industry accounting teams. The practitioners.

Every arrow flows one direction. Down. Standards flow down. Interpretation flows down. Functionality flows down. Everybody tells industry accountants what “right” looks like, how they should think, what they should buy. Only the operators hold the translation of what any of this looks like day to day — how to fit the pieces together when the close is in three days and the auditor is on the calendar and the CFO needs the variance explained by Friday.

The missing piece: there is no arrow flowing up.

The upward channels technically exist. AICPA committees. FEI. FASB’s EITF. There are practitioner seats — but the boards are governed by the firms and vendors who fund them, and membership skews to the largest public companies with 15-person technical accounting teams. The companies where the emerging issues actually live — pre-IPO SaaS, AI-native startups, the private companies doing things the guidance hasn’t caught up with — have no meaningful representation. And all the outcomes are documented by firms and software vendors.

Even inside the firms, the pipes were always human. When I was in L&D at KPMG’s National Office, distributing knowledge consistently across 40,000 professionals was nearly impossible. Trainings were developed over months and delivered once a year. Interpretations were delivered through disparate publications. Signal from the field moved through networks, friends, chance coffee, DMs.

This barely worked when technology transitions took a decade. It shatters with the exponential pace of AI.

Here is the diagnosis, and I want to say it plainly because the empathy in this article only works if the diagnosis is honest. Well-meaning interpretation is being written as thought leadership by people who have never implemented. Software is being written by developers who have never closed the books. The practitioners — the only ones who could bridge both — have no time and no structural channel to push back through. Not because anyone is acting in bad faith. Because the mechanisms were never built.

And both of those interpretations — through thought leadership and through software — are quietly becoming the training data for the AI models the entire profession will be using by next year.

We are not writing what the models learn. They are.

Why Gaapsavvy exists

I started Gaapsavvy when ASC 606, the ‘new’ revenue recognition standard was rolling out. Nobody knew what to do, but everyone had to pretend they did. Each Big 4 firm sent up to 500 open questions to the SEC. The firms were interpreting in parallel with us, often disagreeing with each other depending on which one you sat across the table from.

Practitioners were figuring it out in real time, in isolation, with no one to compare notes with. Sometimes the most important thing to know, is when an answer had not yet been defined yet, and I thought: we get to the answer faster together than alone.

That’s still why we’re here. Except now things are moving way faster with AI.

A new layer needed to exist where industry operators — the people who bridge technical accounting and systems — could connect, exchange ideas, and iterate together. A human network built for ambiguous, large-scale change. A place to give voice to the operator who sees, feels, and lives the whole picture.

Throughout my career, I’ve sat in three seats in this ecosystem — the National Office at KPMG, writing trainings to audit a profession I didn’t live in yet; an industry technical accountant at Glassdoor, where I was humbled by how much harder it was to implement a repeatable process than to write a memo; and building software as part of the founding team at Everest, where I learned that accounting software fails at the infrastructure layer because accounting itself is a memory discipline that needs to be built on a time series — and nobody outside of the profession recognizes it as one.

Each seat sees a slice. None sees all three. The operator who lives all of it — every day, under pressure, with the audit and the close and the CFO all in the same week — sees the whole picture and has no structural way to say so.

Gaapsavvy was built for that operator.

Writing the future

Here’s what’s actually new. Operators are becoming builders. Writing is becoming creating.

For most of professional history, knowledge has been organized around the limits of our human capacity.

Just like medicine has neurologists, cardiologists and dermatologists, we had technical accounting, audit, internal controls, SEC reporting and finops. Each specialty exists because no one head could hold all of it - particularly in enterprise environments as companies scaled and compliance needs increased.

The Controller became the connective tissue, paying a translation cost every time something complex needed to cross a boundary. Aggregating, cleaning and synthesizing data as it came together. Accountants have to explain ASC 606 to a product engineer, then explain the engineer’s response to the auditor, then explain the auditor’s response to the CFO. The auditor who takes a screenshot of a dashboard because they cannot reason about the database underneath it. A software implementation is delayed because the vendor needs the technical accountant to validate an interpretation but waits months for a partner to work the conversation through the national office. Every cross-functional finance conversation has hours of translation overhead embedded in it that produces zero financial value. Nobody tracks the cost. Everybody pays it.

AI is the first technology that meaningfully lowers that translation cost. Not because it replaces specialists — because it lets the integrated practitioner finally act on the whole picture without losing it in translation. The profession isn't being automated. It's being un-fragmented. And the wisdom that has always lived in the operator who does the whole job — and was always lost in the handoff — is finally distributable. We can write it down. We can share it. We can make it count.

And just like it was when ASC 606 was being adopted, no one has the answers yet. We are making it up in real time.

You can see it in one hour

You don’t have to take my word for any of this. You can watch it happen in real time.

Some context for what the April 17 numbers mean. Gaapsavvy runs a shareforum every other month and has for eight years. In 2025, the average was 105 live practitioners per session out of ~150 RSVPs — a 75% show rate, in a profession where 30-40% is industry standard. 100% in-house, no vendors in the room. Across seven sessions, that’s 700+ hours of practitioner discussion. April 17 wasn’t a one-off. It was the same engine running at a bigger throttle, with a higher-profile speaker and a topic the entire industry was figuring out. The room knew how to show up because the room has been showing up.

1,312 attendees. ~500 corporate domains. 81% in-house finance. 160 questions. Three live polls. Read together, they show the shape of the problem the profession is facing.

Poll one — model approval

78% of in-house finance practitioners had Claude approved at their company. 56% had ChatGPT approved. 30% were Claude-only. In the subset of practitioners leaning in enough to show up on a Friday morning, the model landscape has already tipped.

Poll two — Claude capabilities used

More than half had used Claude Code or Cowork. 46% had used Claude in Excel, Docs, or Slides. A third were using MCP connectors. A third were using Skills.

The “industry as builders” thesis isn’t aspirational. It already happened. Controllers and VP Finance are building. Between meetings. With or without permission.

The activation gap

Here’s what doesn’t fit in either chart on its own. Among in-house practitioners who had Claude approved and answered the capabilities poll — 442 people — 54% had used Claude Code or Cowork. 46% had not. And one in five had used no Claude capability productively at all. Just permission.

That gap is where the profession actually is. The constraint isn’t approval anymore. It’s activation — the distance between “your company said yes” and “you actually built something.” Activation isn’t a product problem. It’s a peer-learning problem. The people who crossed the gap learned it from someone who’d already crossed.

If you’re not one of these builders yet, you’re not behind. You’re early. The community is full of people who started six months ago and people who started six days ago, sitting next to each other in the same room.

Poll three — what practitioners actually want built

Three open text questions, answered by 397 people in a blank text box on a Friday morning. The responses don’t read like a survey. They read like a roadmap.

Clustered into product surfaces, in order of demand: FP&A and reporting (flux, variance, forecasting, exec decks — 61 asks, the single biggest cluster). Close and operational accounting (reconciliations, accruals, journal entries, month-end — 100+ asks combined). Revenue, contracts, and order-to-cash (28 asks). AR, AP, and cash (30 combined). SOX and audit (13 asks). Technical accounting memos (11 asks).

That isn’t a feature list. It’s the org chart of the finance function, mapped to a delivery roadmap. Every cluster maps to a specific team, a specific workflow, a specific monthly pain. And the asks get more specific the deeper you go — not “automate accruals” but “a Xero-to-model reconciliation skill that takes actuals, ties them to your finance model, flags variances by line item, and produces a variance commentary draft.”

These are operators describing what they would build, if they could just figure out how.

This one in particular stood out:

“Sharing the Auto-Accrual MJE Hub and selling that to other companies.”

That last one is from an in-house practitioner who has already built the thing, and whose next instinct is to distribute it. That is the future of this profession in one sentence.

The systems

NetSuite was requested 3× more often than any other system. Then Workday, QuickBooks, Salesforce, Oracle. The systems enterprise finance actually runs on. Practitioners aren't asking for new tools — they're asking for Claude to work with the tools they have.

What’s still in their way

The blockers cluster into a shape the article has been arguing all along: training and where to start (27%), time (16%), InfoSec (12%), connectors and integrations (12%), data quality (8%), where builds live (7%), SOX readiness (5%), accuracy and hallucinations (5%). I suspect as teams move access blockers ( training, time and infosec), we will graduate to the deeper problems of data quality, where builds live, SOX and accuracy.

Read it as a sentence. The practitioners aren’t blocked by the technology. They’re blocked by the operational scaffolding around it — the trust, the governance, the integrations, the peer learning, the place where the work lives after you build it. Every one of those is something a community can solve faster than a vendor can.

“Scaling past early adopters. Tooling isn’t the blocker. It’s the change management layer around AI adoption that no vendor owns and every firm underestimates.”

The governance question, asked unprompted

The top-upvoted question in the entire 160-question Q&A, tied at 47, was:

“How does the finance team decide when to use Claude with sensitive finance data, what guardrails are in place, and are there workflows or data types you still avoid using it for?”

The question Zoom couldn’t deduplicate — submitted four separate times, each upvoted to seventeen — was:

“When you create these dashboards, where are they held? This looks brilliant. We are going through the SOX process currently and this looks like such a clean method.”

And further down the list, the question I think will become the question of 2026:

“In finance, we need to audit and recreate past results. How do you use non-deterministic AI tools and still be able to rerun, explain, and stand behind what they produced?”

This is what the practitioner conversation about AI in accounting sounds like when there’s no vendor in the room. Not can it do this. Not is it accurate enough. The questions are about governance, deployment, and reproducibility. The hard problems. The ones nobody has answered.

What this means

Three audiences are reading this section. The data means something different to each.

If you’re a finance leader: Your peers are exactly where you are and further along than you think. 78% approval. 54% active use. 20% with permission but nothing built yet. The distribution is wide because activation depends on whether you’ve seen what’s possible in someone else’s hands. That is what shareforums are for. The next one is the move.

If you build for this audience — software, AI platforms, agents: This is your roadmap. NetSuite first. Reconciliations and accruals as the universal entry point. FP&A and reporting as the volume opportunity. Revenue and contracts where the high-judgment money is. And under all of it, the governance layer that no vendor has solved yet — auditability, reproducibility, where the build lives, how the auditor signs off. The product opportunity isn’t the workflow. It’s the trust scaffolding around the workflow. Whoever builds that first wins.

If you’re a firm or a partner watching this from the outside: The data above did not exist a month ago. It cannot be procured from an analyst firm. It cannot be replicated by a vendor survey. It came out of one room, in 88 minutes, because somebody finally asked the right people the right questions in the right setting. That is what the community produces. The question for partners is whether you want to be in the room when the next set of questions gets asked.

Three weeks later, at the next Gaapsavvy AI session, showed us how fast the cycle now runs — demoing a Slackbot her team built that talks to NetSuite, drafts journal entries, and routes them for human review before anything posts. Her architecture principle is the cleanest I've seen: "AI handles language and judgment. Software handles controls and execution." Practitioners come to a venue they trust, builders show what they've shipped, the community absorbs the patterns, and someone in the audience starts building their own version next week. That's the spine.

The thing we accidentally built

Gaapsavvy isn’t a community with sponsors. It’s an ecosystem of living intelligence where the practitioner voice has become valuable to a specific set of institutions — and the relationships look different because what each institution needs is different.

The community produces three things, and partners access any combination depending on what they need.

Access — a room of practitioners that won't otherwise gather. Deloitte and Gaapsavvy hosted our AI Finance Lab together in their San Francisco office. On April 17, 1,312 in-house finance practitioners came because Adam Dix is one of them — a peer with a similar background to the rest of us, a non-coder who started building with Claude on his own time to solve a real problem. He now runs finance ops at Anthropic. The community trusts itself, which is why it can produce a room like that.

Signal — real-time, peer-to-peer, in-the-room signal about what’s actually working, breaking, or being built between meetings. The polling section above is what Signal looks like in operation. No analyst report, vendor survey, or traditional CAB can replicate it, because in those settings participants are performing. In Gaapsavvy they’re not.

Distribution — what we produce together, traveling faster than partner hours and PDFs can carry it. Practitioner-validated interpretations. Governance frameworks. Reusable skills like the Auto-Accrual MJE Hub the respondent above wants to share with other companies. When Gaapsavvy published our EU Data Act analysis last fall, it traveled through practitioner networks and into firm conversations — read by advisors before they walked into client meetings, and cited back to auditors by clients themselves. The community wrote the canon. Distribution happened because what got written was practitioner-aligned. The community as the editor.

One rule unifies all three. The practitioner voice is the asset. Everything else flows from honoring it. Partners who treat it well thrive. Partners who treat it as a sales channel get quietly exposed by the people whose voices they were trying to use. The self-correction is part of the design.

What needs to exist

What needs to exist is a new thing. Not another interpreter. Not another vendor. Not another auditor. A practitioner-governed body whose entire job is to carry signal in two directions.

Up: the wisdom of 1,200 practitioners flowing into the rooms where standards get set, audit frameworks get written, software gets shipped. A seat at the table the profession has never had.

Out: that same wisdom curated into something the profession can use. Not partner hours at partner rates, delivered through a slide deck. Intelligence on tap. Practitioner-validated finance skills — built once, audited by the community, customized to your stack, available at the point of need. The delivery mechanism for wisdom that used to live in partner heads and National Office libraries.

This isn’t a future I’m proposing. It’s a structure that already exists in practice, being asked to formalize itself by the practitioners who built it. The wisdom is theirs. The technology is the carrier.

All of accounting is about memory — how the past affects the future. That’s the whole job. The profession that has kept the world’s memory for 600 years is finally meeting the technology that is learning how to remember. And the canonical memory of professions is being formed in AI right now, in the corpus the models are training on. The professions that don’t show up to write themselves will be misrepresented by the ones who did.

We can either show up and write it together — in community — or we can let it be written for us by the people whose view of the profession has always been partial.

I’ve spent eight years carrying this thesis without the proof. April 17 was the proof.

The community is here. The room is open. Show up and write it with us.

— Angela

What’s coming up:

May 29 — QTC Shareforum. The next Gaapsavvy knowledge share session based on Q&A from the community. In house practitioners only. Join the community here.

June 17 — Gaapsavvy × Zuora: Usage-Based Rev Rec Working Session. In-person, SF. Limited seats — curated for practitioners actively working on usage-based models. This is exactly what this article describes — practitioners and a vendor's product team working through how ASC 606 interpretation adapts to evolving usage models and translating to software builds in real time. Application required. Request an invite.

Partners and platforms thinking about how to plug in to what comes next — find me at angela@gaapsavvy.com.

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.

Read more

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 sha…

Read more

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 outsour…

Read more

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…

Read more

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 ac…

Read more