Tax Software Needs Real APIs

A tax practice does not operate inside one application. Information arrives from accounting systems, payroll providers, clients, prior returns, spreadsheets, and document stores. Prepared information then has to move into review, delivery, planning, and the next year’s work.

Every poorly connected boundary creates another place to copy, reformat, reconcile, or lose context. The burden often falls on the professional who understands the information well enough to move it safely.

An API is a defined way for software systems to communicate. In professional tax software, it should be an ordinary part of the product’s architecture. It should let a practice build useful connections without relying on fragile screen automation or treating every integration as a special commercial negotiation.

This is one of the motivations behind PrepReturns. It is also a direction, not an announcement that a public production API or live partner integration is available today. The interesting question is what an API for preparation should actually make possible.

Moving a value is the easy part

It is tempting to define integration as getting a number from one system into another. But an amount without context is only partially useful.

What period does it cover? Which entity or person does it belong to? Is it a source reading, an accepted fact, an estimate, or a derived result? Is the amount expressed in cents or whole dollars? Has a preparer reviewed it? What happens if the source changes tomorrow?

Those questions exist whether the transfer happens through an API, a CSV, or a person typing into a screen. An API makes it possible to answer them explicitly and consistently. A weak interface simply automates the ambiguity.

For tax work, useful interoperability needs to carry meaning and state as well as values. Otherwise, a fast integration can create a faster reconciliation problem.

Start with the jobs a firm needs to do

The best API design begins with concrete workflows. A firm might want to bring in a supported set of book accounts, attach source context, and present proposed classifications for review. Another might want to identify unresolved questions across cases. Another might need to retrieve the manifest and files for a particular saved preparation.

These are different jobs with different authority requirements. A tool that proposes an account mapping should not automatically gain the right to establish a tax fact. A tool that retrieves a saved package should not have to reproduce the engine’s calculations in order to understand which files belong together.

A useful interface would name those operations clearly. It would explain their inputs, results, review consequences, and failure conditions. It would also make read-only uses practical, because many valuable integrations need to inspect information without changing it.

The objective is to let outside tools participate in a well-defined preparation process, not require them to imitate the entire application.

Review is part of the contract

An integration should not become a shortcut around professional authority.

Imagine a future connector that brings financial information into PrepReturns. The connector may know that an account is labeled “Owner Benefits.” It may even have a suggested mapping. That does not establish every tax fact or treatment associated with the account.

The interface should preserve the distinction between proposing information and accepting it. A preparer should be able to see the source, assess the suggestion, and resolve remaining questions. If a later synchronization changes a reviewed amount, the system should handle the review consequences deliberately.

This is the same boundary used in source-driven preparation. External automation should enter that architecture rather than bypass it.

An API that can only write directly into final fields would make the system easier to connect and harder to trust. The richer design is an interface to the workflow itself: evidence, proposals, established facts, preparation, and saved output.

Errors deserve useful names

Developers often discover the real quality of an API when something goes wrong. A successful response to a perfect request is the easy demonstration.

Suppose an integration submits an amount while another user has changed the related case. Or it retries a request after a timeout. Or it references a source that has been superseded. Or it sends a value for a capability the current engine does not support.

These conditions need distinguishable outcomes. “Request failed” is not enough for a tool to decide whether to retry, refresh, ask the preparer, or stop. Silent partial success can be worse, because it leaves the integration unsure which work actually happened.

An API intended for professional workflows should document conflict behavior and safe retries. The same request should not accidentally create duplicate adjustments. An older view of a case should not silently overwrite newer professional work.

These are design requirements for the intended direction, not claims that every public endpoint already exists. They follow directly from the state and history problems the product has had to confront internally.

Versions are about meaning

Versioning is sometimes treated as a path naming convention. In tax software, it is a deeper obligation.

An integration may rely on a field’s meaning, a calculation boundary, a review prerequisite, or a saved package’s structure. A change that preserves the field name while altering one of those assumptions can still break the workflow.

Tax-year differences add another dimension. A caller should not have to infer which rules or domain version an output belongs to. The identity of a prepared return matters when another system consumes it later.

Good documentation would describe what is stable, what can evolve, and how incompatible changes are introduced. Example payloads should demonstrate missing and unsupported states as well as successful cases. Tests should exercise the contract an integrator actually relies on.

An API becomes infrastructure when people can build against it with a reasonable understanding of how it will change. That responsibility does not disappear because the team building it is small.

Export is a professional capability

Some of the most valuable interoperability is outward-facing. A practice should be able to retrieve meaningful output from the work it has completed.

A PDF is essential for many review and delivery tasks, but structured information can support other uses. A future downstream tool might need a shareholder package’s identity, the related corporate preparation, selected reported amounts, or unresolved boundary information. A research or comparison tool might need a synthetic case’s inputs and expected outputs in a stable form.

The exported representation should be clear about what it is. A corporate reporting amount is not necessarily the final result of every individual-level limitation. A saved workpaper is not an instruction to recalculate the return using a different set of rules.

This is especially relevant to the planned Form 1040 engine. The long-term business-to-owner connection should pass structured shareholder information across a defined boundary. It should not couple two different tax domains so tightly that neither can be understood or changed independently.

Related products are not automatic integrations

PrepReturns grew out of Trio Tax. Trio Ledger is a sibling product focused on straightforward small-business bookkeeping. That relationship gives the projects useful common context.

It does not establish a live integration between them.

The distinction is worth making because product-family diagrams can create expectations faster than engineering can fulfill them. A link between two brands is not a data contract. Shared ownership does not settle mapping, review, source identity, or change handling.

An eventual connection should be evaluated on the same terms as any other integration: what information moves, what meaning is preserved, what the preparer must review, and what happens when the systems disagree.

Building from the practice outward gives us concrete problems to solve. It should also make us more demanding about the quality of the connections we propose.

Access should be predictable

Interoperability has a commercial side. A technically capable API can still be difficult to use if access is opaque, narrow, or priced as an exceptional privilege.

There are legitimate costs in operating, supporting, securing, and maintaining an interface. The argument is not that these responsibilities cost nothing. It is that integration should be treated as a normal professional need, with clear terms and useful scope.

A practice evaluating software should be able to learn which operations are supported, what data it can retrieve, which limits apply, and how a prototype can be tested. Technical questions should have technical answers.

This is a general product position, not an allegation about a named vendor or a claim about today’s market-wide pricing. The frustration that motivates PrepReturns is the gap between how interconnected practice work is and how difficult some software boundaries can make ordinary cooperation.

Open source could change who can solve the problem

PrepReturns is private today, with open source as the intended direction. If a future release provides appropriate rights, firms and developers could inspect the integration boundaries, contribute improvements, or maintain an extension for a particular workflow.

That possibility changes the feature-request conversation. A useful endpoint would not have to wait indefinitely for one vendor’s priorities to align with one firm’s needs. The firm could contribute work, hire someone, or explore a maintained fork.

Openness would not remove the need for stable contracts. Nor would it make a tax-logic modification safe merely because it is possible. Review, tests, compatibility, and professional responsibility would remain essential.

The benefit is agency: more people could participate in solving the problem. The open-source direction is about that relationship as much as access to code.

Build connections that deserve to stay connected

A real API should make the architecture of a preparation system clearer. It should identify the difference between source evidence and accepted facts, distinguish current work from saved history, and provide useful access to supported operations and output.

That is a higher standard than exposing every internal function. It asks the product to define what outside software may rely on.

PrepReturns has not completed that public API future. The project does have a concrete reason to pursue it: the tax practice is already a network of information and tools, and repeated manual handoffs are not a satisfying long-term interface.

We are interested in comparing notes with practitioners, engineers, and software companies about these boundaries. The productive conversation begins with a real workflow and a clear account of what information needs to move. From there, interoperability can become part of the preparation system’s normal design.