Finance & Automation Blog · 5 MIN READ

Solving Kraken's Manual GL Flux Analysis Problem with a NetSuite Claude Skill

Month-end accounting at Kraken involved a highly manual process for understanding General Ledger (GL) flux.

The accounting team needed to understand what changed month over month, identify the biggest drivers, investigate the underlying transactions, determine whether the movement was legitimate or an error, and prepare a clear explanation for review and management reporting.

The challenge wasn’t a lack of accounting expertise. It was that a lot of that expertise was being spent on repetitive data extraction, pivoting, investigation, and commentary preparation. For example, an accountant would notice that a vendor like PWC drove a month-over-month increase, then manually dig into the underlying NetSuite GL transactions — invoices, bills, journal entries — to figure out whether it came from an accrual, an invoice, a cost increase, or something else.

There was also a control angle. The team needed to catch cases where a large movement was actually caused by an accounting error, like a duplicate journal entry.

Kraken needed a scalable way to analyze GL flux directly from the underlying NetSuite data, identify the biggest drivers, investigate the transactions behind those movements, and generate evidence-based explanations without manually repeating the entire investigation every month.

The Solution

We connected the NetSuite MCP server to Claude and built a NetSuite Flux Analysis skill. It runs against a given accounting period, identifies every account where the variance from the prior month exceeds a predefined dollar threshold — for example, $10,000 — and only investigates those accounts. That threshold is what replaces the old, manual judgment call of “which changes are worth chasing.”

We didn’t just ask an AI model “why did this account change?” Instead, we encoded the accounting team’s own investigation process into the skill: what data to pull, how to compare periods, how to find the largest drivers, when to drill into transactions, what counts as evidence, what checks to run, and how to structure the output. That’s what makes it repeatable instead of just another open-ended prompt.

Getting Started

To stand up the skill for a given entity or account group, you’ll need a few things in place:

Architecture

The skill.md file is the operating procedure for the analysis. It turns the manual process into eight steps:

• Step 1 — Connect to NetSuite. Claude pulls GL data directly through the NetSuite MCP connection, instead of someone running a report and exporting it to Excel.
• Step 2 — Retrieve the relevant GL data. The skill pulls transaction-level data for the account and period in question: account, transaction type, document number, description, memo, debits, credits, vendor, entity, accounting period, and PO info where available. All of it — including the memo text used later for evidence — comes directly off the NetSuite GL record, not a separate system.
• Step 3 — Calculate the month-over-month flux. The skill compares an account’s ending balance between the two periods — not individual transaction-to-transaction differences — to calculate the net movement, then filters to the accounts crossing the $10,000 threshold. In practice, explaining the accounts that cross that bar is enough to account for roughly 80% of the total dollar variance for the period, which is enough for a meaningful management explanation without chasing every small movement.
• Step 4 — Drill into the biggest drivers. For each flagged account, the skill pulls the individual GL transaction lines — invoices, bills, journal entries — booked to that account in the period, not just the aggregate balance.
• Step 5 — Use transaction evidence. The skill leans on the transaction data and memo text pulled in Step 2 to back up its explanation. The rule we built in: explain what the data supports, don’t guess.
• Step 6 — Flag anomalies. The skill checks each flagged account for two specific patterns: duplicate journal entries (same amount, account, and vendor posted more than once in the period) and unusually large individual transactions relative to that account’s typical activity.
• Step 7 — Generate the explanation. It writes up a structured, cited explanation for each flagged driver, which the accountant then reviews and can push back on.
• Step 8 — Produce a structured output. It generates an Excel file with the analysis and the supporting GL detail, so the accounting team has something concrete to check against.

Where This Has Helped

A typical case: the skill flags that PWC drove a month-over-month increase past the $10,000 threshold, pulls the GL transactions and memos behind that vendor for the period, and determines whether the driver was an accrual, an invoice, or a cost increase — with a cited explanation instead of a guess.

From Pilot to Production

Right now we’re focused on Phase 1: general accounting and corporate GL flux analysis. We chose this scope on purpose, to first prove out the core capability — can AI reliably do the kind of granular GL investigation accountants currently do by hand?

From here, the plan is to move up through the reporting workflow — each phase below builds on the flagged-account output from Phase 1:

• Phase 2 — Account Consolidation. Take the explanations for individual GL accounts and roll them up into higher-level categories automatically.
• Phase 3 — CFO-Level Reporting. Generate a higher-level narrative that answers what changed this month, what drove it, why, whether there were any errors, and what management should know.
• Phase 4 — Additional Business Context. Combine GL data with operational context where the GL alone doesn’t tell the whole story — for example, explaining a salary increase using headcount data.
• Phase 5 — Learning from Reviewer Feedback. When an accountant catches something the AI missed or got wrong, feed that back in so the workflow improves over time.

Impact

A few other things worth calling out:

• It focuses on the biggest drivers rather than every movement — accounts crossing the $10,000 variance threshold, which in practice covers about 80% of total dollar variance.
• It moves fast from variance to root cause: account → vendor → transaction → memo → explanation.
• It’s a control improvement too — duplicate entries and unusually large transactions get surfaced automatically instead of relying on someone noticing them.
• The accountant still owns the call. They validate the explanation and decide what, if anything, needs to happen next.

What’s Next

This is just the beginning. Next, we’ll be working on more use cases, more specialized skills, and more MCP servers to automate additional workflows across Kraken’s Finance and Legal teams.