06-reference/research

midmarket variance analysis data inputs

2026-07-19·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
variance-analysismacbrigade-railerp-integrationfpa

Mid-Market P&L Variance Analysis: Data Inputs, Taxonomies, and What the Big Three ERPs Will Actually Give You

The question

What are the standard data inputs, formats, and variance category taxonomies that mid-market finance teams ($50M–$500M revenue) use for monthly P&L variance analysis, and how do NetSuite, Sage Intacct, and QuickBooks Enterprise export them?

Context: the ab-managerial-accounting brigade is under active build and MAC's client-reporting use case hinges on automating variance commentary. Source-system data shapes must be known before the brigade can be scoped against real deliverables.

What we already know (from the vault)

What the web says

Convergences and contradictions

Synthesis for RDCO

The taxonomy the brigade needs is not the taxonomy it built. Mid-market monthly variance analysis runs on a comparison-basis grid crossed with a cause-category vocabulary, not on standard-cost decomposition. The comparison bases are four, each computed MTD and YTD, each as both dollar and percent: actual vs budget (original annual plan), actual vs latest forecast/outlook, actual vs prior period, actual vs prior year same period. The cause categories that show up in real commentary are volume, rate/price, mix, timing/phasing (spend slipped a month), one-time vs run-rate, headcount-driven (headcount × rate), accrual true-up or release, reclass/mapping change, allocation change, and FX (translation vs transaction). Standard costing shows up only for the subset of clients who manufacture. The correct move is not to rewrite the shipped skill but to add a sibling skill for FP&A budget-vs-actual commentary and let the brigade's use-case menu route between them. The shipped skill stays valid for the manufacturing ICP.

On automatability, the three vendors are not one tier, they are three. Sage Intacct is genuinely automatable end to end: one call to get_accountbalancesbydimensions with contentselection = Actual and Budget returns actual, budget, and difference grouped by any dimension combination, with readReport handling volume. NetSuite is automatable with real work: the API gives you transaction lines and the account master, so the brigade must reconstruct statement structure, sign conventions, and rollups itself, or the client must pay for SuiteAnalytics Connect (a licensed add-on, so it is a commercial gate not just a technical one). QuickBooks Desktop Enterprise should be scoped as human-export-step for v1: the qbXML path requires an on-prem Windows connector, returns a presentation grid whose hierarchy must be inferred from rowType and subtotal placement, and cannot filter by account at all. Quoting a QuickBooks Enterprise client the same automated-ingestion SLA as an Intacct client would be a mistake, and the difference is worth pricing differently.

The build should target a canonical intermediate schema, and the adapters should be the disposable part. Something on the order of period, entity, account_id, account_name, account_path, statement_section, department, class, location, project, scenario, amount, currency — where scenario ∈ {actual, budget, forecast, prior} — lets the variance engine, the materiality gate, and the commentary generator be written once against a stable shape. This is a plain data-engineering move and it is squarely the founder's muscle, which makes it a credible MAC content cluster as well as a build decision. Account hierarchy handling differs enough per vendor to justify the abstraction on its own: Intacct treats account groups as a first-class reporting-structure object, NetSuite uses parent-child plus summary accounts on the account record, and QuickBooks nests sub-accounts. Typical mid-market depth is three to five levels over roughly 200–800 GL accounts.

Where the joins get ugly is where the engagement risk lives, and it should be surfaced in scoping, not discovered in delivery. The most common hard blocker is budget grain below actual grain: budgets are frequently loaded at department level only while actuals post at department + class + location + project, which makes sub-department variance mathematically undefined. Close behind is that for most mid-market teams the budget does not live in the ERP at all — it lives in Excel or a planning tool, meaning the budget adapter is a separate integration from the actuals adapter every time. Then: nullable dimensions on top-side adjustments and accruals producing an "Unassigned" bucket that no owner will claim; intercompany eliminations, where consolidated P&L is not the sum of entity P&Ls and elimination entries land on a plug entity; allocation JEs that post after the first close draft, so variance run timing changes the answer; FX, where a variance in reporting currency can be entirely translation with zero local-currency movement; mid-year account reclasses that silently corrupt prior-period comparison because none of these systems export effective-dated COA history cleanly; and 4-4-5 or 13-period fiscal calendars, which is why Intacct's reportingperiodname is a named-period string rather than a date range. Finally, sign convention: favorable/unfavorable flips by account type, NetSuite stores credits negative on transaction lines while reporting revenue positive, and QuickBooks pre-signs values for display. Getting F/U backwards on a client deliverable is the single most embarrassing available failure, and it is a one-line bug.

Why this is in the vault

This brief is the input that lets the ab-managerial-accounting brigade be scoped against a real client deliverable instead of against a textbook: it establishes that the already-shipped variance-analysis skill (variance-analysis-ticket, merged PR #6) solves standard costing while MAC's client-reporting use case needs FP&A budget-vs-actual commentary, and it supplies the vendor-by-vendor automatability tiering (Intacct automatable, NetSuite reconstructable, QuickBooks Enterprise human-export) that should drive both the adapter build order and differential pricing per client ERP.

Open follow-ups

Related

Sources

Vault

Web

Verification note: QuickBooks Desktop connector operational requirements (company file open, single-user mode, interactive Windows session) and the absence of a cloud-callable REST API for QuickBooks Desktop Enterprise could not be confirmed from an Intuit primary source and are carried as unverified. NetSuite SuiteQL/REST capability is secondary-sourced only; Oracle's canonical extraction page does not mention it.