Accounting firms don't operate on a single system. They operate on dozens. Different tax engines depending on the return type. Multiple portals for client intake. A workflow manager for assignments and deadlines. Systems for binder and document management. A CRM. A billing system. Time tracking. And email and shared drives filling the gaps between all of them.
When firms evaluate Accrual, the question comes up early: "How does this fit with everything else we use?" This post explains how we think about integration, what we've built to support it, and why we took the approach we did.
Most of today's accounting tools are closed systems. Integrating them requires coordinating vendor roadmaps, working around poor data mapping, and troubleshooting issues at every handoff. The cost is high enough that most firms default to the tools they already have, not because they're the best, but because they're the least painful to maintain.
Sidd, co-founder and CTO of Accrual, puts it simply: "Firms have lots of software to the point where there is a defragmentation of tools they use. But importantly, the walk between systems is human. There are things that pick up documents from one piece of storage and drop them into another piece of storage. We just think that's a terrible way to spend your time."
And accounting firms can't rip out and replace everything at once. Tax, audit, and advisory practices each have different busy seasons that overlap in ways that make simultaneous migrations impractical. Even within tax, transitioning from one client portal to another has to be managed client by client, office by office. When Armanino rolled out Accrual's client portal, for example, they had to coordinate a clean cutoff from TaxCaddy, manage clients who kept uploading to the old system, and stagger invitations across five offices to avoid deliverability issues.
At the same time, firms are exploring automation and agentic AI systems that can operate across their practice: tools that pull data from multiple sources, act on it, and coordinate workflows without manual handoffs. Those systems need open platforms to connect to. The solution isn't to build yet another closed system that adds one more silo. It's to build an open platform that can connect to the tools that exist today while offering a clear path to consolidation over time.
Our guide for converting successful pilots into operational deployments covers the practical side of this. Firms build confidence through phased rollout. A Top 20 firm might start with 25% of their 1040 practice in year one. A regional firm might begin with a single office. The platform has to support that incremental path, not demand an all-or-nothing commitment.
"API-first" can mean a lot of things. In practice, many vendors build their own product on one set of internal tools, then offer customers a separate, more limited version. The customer-facing API has fewer capabilities, stricter rate limits, and less reliable documentation. New features show up in the product months before they're available through the API. Breaking changes ship without notice. And API access itself is often gated behind an enterprise pricing tier.
We took a different approach. Accrual's founding engineers spent over a decade at Stripe, where they helped build the APIs that now process over 1.6% of global GDP at 99.999% uptime, less than five minutes of downtime per year. API design at that scale teaches you things that are hard to learn any other way: that backwards compatibility is sacred, that breaking changes destroy trust, that documentation itself is a product, and that the best APIs are the ones developers never have to think about. We brought that discipline to accounting because we believe firms deserve the same quality of developer tooling that fintech companies have had for years.
This also reduces lock-in risk. Every piece of data in Accrual is accessible through the API. Firms can export clients, documents, engagements, and worksheets at any time, in standard formats. The tax engine remains the system of record for filed returns. The platform is designed so that firms gain the benefits of consolidation without the risk of dependency.
The same API powers everything. Accrual's web application, client portal, internal tools, and customer integrations all consume the same API. There is no separate "public" layer with fewer capabilities. When we ship a new feature, the API endpoint is available immediately, because our own product depends on it.
Modern documentation and SDKs. Our API documentation and SDKs are generated through Stainless, the same tooling used by companies like OpenAI and Anthropic for their developer platforms. The docs are complete, versioned, and include typed SDKs. We treat the developer experience the same way we treat the practitioner experience: if it's hard to use, people won't use it.
API access is included. API access is included for every firm. We don't charge extra for it, we don't gate it behind an enterprise tier, and we don't throttle it to push firms toward the UI. If a firm wants to build a custom client portal, automate their onboarding workflow, or connect Accrual to their internal systems, they can do that without a commercial conversation.
Why do APIs matter? Most of the people who need platform data aren't engineers. They're practice leaders checking rollout progress, tax managers monitoring their team's engagement pipeline, or operations staff tracking portal adoption across offices. Traditionally, getting them that data means building a dashboard. Every firm has a version of the PowerBI project that's been on the roadmap for two years: the one that would finally give leadership real-time visibility into their practice. It either never gets built, gets built once and never updated, or gets built and sits unused because daily refreshes aren't fast enough when partners want real-time answers during the height of tax season.
This is why we built a server using the Model Context Protocol (MCP), an open standard that lets AI assistants connect directly to external data sources. In practice, this means firms can interact with their Accrual data through tools they already use: Microsoft Copilot, Claude, OpenAI, or any AI assistant that supports the protocol. Instead of logging into a dashboard or writing an API call, a practice leader can ask "which Dallas office clients haven't accepted their portal invitation?" and get an answer drawn from live platform data.
This reflects an important principle for us: the data belongs to the firm. Our job is to make it as easy as possible for them to access it, analyze it, and integrate it into their own workflows, whatever form those workflows take.
Examples of how customers use the API in production.
Custom rollout monitoring. Armanino uses our MCP to let their project management team monitor the rollout without needing access to Accrual's UI. They build internal dashboards, track operational KPIs for the tax season, and identify returns that don't follow the firm's standard operating procedures. Early in the season, that might mean flagging binders that haven't been sent to clients yet. Later in the season, it might mean surfacing tax returns that have been reviewed but not exported to the tax engine. These are the kinds of signals that help leadership spot where additional training or intervention is needed, office by office, partner by partner, before small gaps become systemic issues.
Existing portal integration. Some firms have their own client portal that handles invoicing, engagement letters, and cross-practice tracking. They don't want to abandon that portal for tax season, but they do want Accrual's document processing and preparation capabilities. The API lets them keep their portal as the client-facing layer while routing documents and data into Accrual for preparation.
Bulk operations and automation. Onboarding thousands of clients across multiple offices isn't something you do one at a time in a UI. But it's also not as simple as uploading an Excel sheet. Client data lives across multiple systems, and it rarely agrees. Email addresses in the CRM don't match the tax engine. A client's name changed after a marriage but only got updated in one system. Duplicate records need to be identified and merged. Life events tracked by the partner need to be reconciled against what the tax engine shows. Firms use the API to script this reconciliation: pulling data from multiple sources, resolving conflicts programmatically, and importing clean, validated client records into Accrual. What would otherwise take weeks of manual review and spreadsheet wrangling happens in hours.
Internal operations. Our own customer success team uses the same API for day-to-day work. During portal rollouts, they monitor invitation delivery in real time: which emails bounced (and whether the bounce was temporary or permanent), which clients opened but didn't accept, and how reminder cadences are performing across different firms and offices. If a batch of invitations hits a deliverability issue, the team can identify the affected clients immediately and coordinate with the firm to update addresses or adjust send timing. We don't have a separate internal tool for this. We use the platform the same way our customers do.
We believe the best long-term operating model for firms is unified: fewer handoffs, fewer disconnected systems, better visibility, and a stronger data foundation across the workflow. The data from this tax season supports that: 77% portal acceptance rates, 99.9% success rate for document processing, 99.7% of worksheet edits drafted by AI. That level of insight only exists because the full workflow ran through a single system.
More importantly, a unified platform compounds over time. The client portal isn't just a one-time document upload. When the agent identifies a gap during preparation, it can surface a follow-up question directly to the client through the same portal they already used. Documents uploaded in one season carry forward to the next, giving the agent an even stronger starting point for preparation. Client profile information builds a graph across engagements: when multiple partnership returns are filed for related entities, the system understands those relationships and uses them to improve accuracy and catch inconsistencies. None of this works if documents live in one system, client communication lives in another, and preparation lives in a third. The compounding effect requires a shared data layer.
But we also believe that getting there requires patience. A firm with a dozen existing tools, overlapping busy seasons, and thousands of clients across multiple offices isn't going to migrate overnight. The platform has to complement those tools, not compete with them. And when the firm is ready to consolidate, the transition should be gradual and low-risk.
That's why every feature we ship is available programmatically from day one.
To learn more, reach out to your account team or contact us.