Tax calculation, inside your product

What already exists

A deterministic engine covering federal income tax and FICA, income tax for all 51 state jurisdictions, and local income tax for 3,672 jurisdictions across 7 states — every Pennsylvania municipality, every Ohio municipality and school district, Indiana's counties, Maryland's counties, Michigan's cities and New York City's statutory brackets.

Property tax for all 3,143 US counties as effective rates computed from tax actually paid, which is the only property figure comparable across state lines.

Specialist engines for self-employment tax and QBI, capital gains with correct stacking on ordinary income, the provisional income rule for Social Security, rental income with depreciation and passive-loss limits, the refundable credits, and estimated tax safe harbours.

And the thing that is harder to replicate than any of it: every figure carries the document it came from and the date it was checked. Of 37 states checked against their own department of revenue, 12 carried a wrong rate, threshold or credit in the compiled sources most products are built on.

Who this tends to be for

Payroll and HR products that need take-home figures including the state and local layer, which is the part most off-the-shelf data sets omit.

Financial planning and advice tools that model scenarios — a move, a raise, a retirement drawdown order — and need the arithmetic to be defensible when a client asks where a number came from.

Real estate and mortgage products that need property tax by county rather than by state average, because the spread inside a single state is frequently larger than the spread between states.

Publishers and comparison sites that want calculators without maintaining tax data themselves, which is a continuous obligation rather than an annual one.

And anyone who has discovered that the tax figures in their product are a year out of date and has no process that would have caught it.

Three ways to use it

The open API. Documented, no key, 60 requests a minute per address, no availability commitment. Free, and enough for a prototype or a low-volume feature. Start there before talking to anyone.

Higher volume with a commitment. The same endpoints with a key, a quota that fits your traffic, and an availability arrangement. This is a conversation about what your volume actually is rather than a price list.

White label. The calculator interfaces, styled to your product, either embedded or rebuilt against the API. The advantage over the free widget is that it is yours, without the attribution link.

Custom logic. Cases the public engine does not model — an industry-specific deduction, a jurisdiction we have not loaded, a scenario engine over the existing calculations. Scoped case by case, and we will say when something is not worth building.

What we do not do is sell a data dump. The value is in the engine plus the verification process, and a snapshot of rates goes stale in exactly the way this whole site exists to argue against.

Getting in touch

Useful things to include: what you are building, roughly how many calculations a month, which jurisdictions matter to you, whether you need the API or the interfaces, and your timeline.

The jurisdiction question is the one that most changes the answer. Federal-only is straightforward; federal plus all states is what already exists; a specific set of municipalities may already be loaded or may be a piece of work.

The form below sends an email to hola@prqdigital.com and does nothing else with what you type — no database, no list, no automated sequence. If you would rather write directly, that address works just as well and reaches the same person.

If the form ever fails to deliver, it will say so and give you the address rather than showing a confirmation. A form that quietly swallows a message is worse than no form at all, which is why this one did not ship until there was a mailbox behind it.

The API is open and documented if you want to evaluate the engine before speaking to anyone. That is the order we would suggest anyway.

The part that is harder than it looks

Building a bracket calculator takes an afternoon. Keeping the rates behind it correct is a continuous obligation, and it is the part that quietly fails inside products rather than at launch.

Fifty-one jurisdictions on fifty-one legislative calendars, with no common publication date and no single document. Several states enact rate changes mid-year with retroactive effect to 1 January, which invalidates anything compiled in the first half of the year without signalling it.

And the structural traps that a rate field cannot express: a "flat" state that taxes nothing below a threshold, a withholding table that is not a rate schedule, a local jurisdiction whose name exists in twenty-two counties at six different rates. Each of those produced a wrong figure somewhere in the sources we checked.

The reason this is worth buying rather than building is not the arithmetic. It is that somebody has to open 51 department of revenue publications on a rolling basis and record what they found, and the cost of that does not fall as your product grows.

How an engagement tends to go

Evaluate first. Use the open API against your own real cases before anything else. If the coverage or the data does not fit, that is much cheaper to discover in an afternoon than in a contract.

Scope the gap. Most conversations are about a specific missing piece rather than the whole engine: a jurisdiction, a scenario, a response shape. Naming it precisely is most of the work.

Agree what current means. Different products need different things from a tax data set. A payroll product needs the local layer to be right; a planning tool needs scenarios; a content site needs breadth. The verification cadence that matters differs accordingly.

Then the commercial part, which is volume, availability and support. It comes last because it is the easiest to settle once the first three are clear.

We will also say when something is not worth doing. A product that needs one state and one bracket table does not need any of this, and telling you so costs us a small engagement and saves you a dependency.

What you would actually be buying

Not a rate table. Rate tables are freely available and are exactly the thing that goes stale inside a product without anyone noticing.

What is on offer is an engine plus a verification process: the arithmetic for every structure the fifty-one jurisdictions actually use, and the ongoing work of checking each figure against the publication that sets it and recording when.

Plus the parts that are only visible once you have tried to build this: the local layer, the exempt bands that make a flat state not flat, the difference between a withholding table and a rate schedule, and the jurisdictions whose names repeat across counties at different rates.

And provenance in every response, which is what turns a figure in your product into one your support team can defend when a user disputes it.

Questions

What does it cost?

The open API is free within its rate limit. Beyond that, pricing depends on volume and on what availability you need, which is a conversation rather than a published tier — and we would rather have it after you have evaluated the free endpoint.

Can I try it before talking to anyone?

Yes, and we would prefer you did. The API is documented and open with no key at 60 requests a minute. Evaluate the engine and the data first; the commercial conversation is easier when you already know whether it fits.

Do you cover local income tax?

Yes — 3,672 jurisdictions across 7 states, each read off the state's own published rate file. It is the layer most tax data sets omit entirely, and in several cities it exceeds what the state takes from a modest salary.

How do you keep the data current?

Every figure is read off a primary source and stored with the document and the date. State figures are checked on a rolling basis rather than annually, because state legislatures change rates mid-year and backdate. The changelog records every change.

Can you build tax logic we need that you do not have?

Sometimes, scoped case by case — a jurisdiction not yet loaded, an industry-specific rule, a scenario engine over the existing calculations. We will also say when something is not worth building, which is more often than you might expect.

Do you sell the raw tax data?

No. The value is the engine plus the verification process together; a snapshot of rates goes stale in exactly the way this site exists to argue against, and selling one would undercut the only thing that makes it worth using.