processing-time

Status: published. 51 of 51 jurisdictions, last verified 2026-08-09. Both halves of the record are now collected as far as this network can reach them; see Coverage below for what remains open and Known dates that will move this data for when it is next worth re-reading.

Per-jurisdiction record of how long a state takes to process an LLC formation filing, and what it costs to make that faster. One JSON file per jurisdiction in states/<slug>.json.

This namespace is additive: it adds no key to states.json, entitysearch-state-data, name-rules or dba-rules, and nothing already published changes because of it. A consumer that ignores this directory sees exactly the dataset it saw before.

Why this namespace exists separately

The fact "how long does it take" is not one fact. It is two, and they behave nothing alike:

Folding both into one field would make half of every record wrong within a month and would quietly erode the meaning of lastVerified across the repository. So the schema keeps them in two objects with different contracts, and the standard-time object is explicitly framed as an observation, never as a current value.

Scope boundaries

• Formation filings only. Time-to-process for the Articles/Certificate of Organization. Amendments, dissolutions, and foreign qualification are out of scope for now.
• Name reservation processing time stays where it is. name-rules's nameReservationProcessingTime is authoritative for that fact and this namespace does not restate it. One fact, one field.
• This namespace is authoritative for expedited-service fees and turnarounds. Any other mention of them anywhere in the dataset is prose, not a value to be read.
• No formation-service pricing. An expedite fee is what the state charges. What a filing company charges to click the expedite box is not data.
• Registered-agent, shipping and card fees are out of scope, the same way they are for the fee namespaces.

Sourcing

Held to the same standard as the rest of the repository: the published policy in the root README.md §Methodology. Every figure is read from the agency's own fee schedule, service-options page, or the statute that sets the fee. No blogs, no formation-service pages, no commercial aggregators — including as corroboration.

The one conflict is resolved. The root README's What is excluded list used to read "Expedited-processing surcharges […] are excluded." That was written about cost basis — an expedite surcharge is not folded into a fee or total-cost field — but read as an unqualified exclusion, this namespace would have contradicted it. The heading is now What is excluded from the fee figures, and the sentence says explicitly that expedite surcharges are excluded from the cost basis, not from the repository, and are recorded as their own value where recorded at all.

Field dictionary

Identity

expedite — the stable half

standardProcessing — the volatile half

Provenance

sources[] (citation, title, url, lastAccessed) and notes carry their usual meaning. lastVerified covers the expedite object; it deliberately does not cover standardProcessing, which carries its own observedOn.

Every value here is bound to the words it was read from. Each tier carries an evidence object — a passage quoted from the cited page, plus that page's URL — and each quotation is checked mechanically to occur in the page as retrieved. A quotation that does not occur is a rejected value, not a warning. lastVerified is the date of that retrieval and that check.

This is a deliberately different promise from "someone looked at it", and a stronger one: a reader cannot audit whether a person opened a page, but anyone can re-fetch these pages and re-run the substring check. It is also not a complete one — grounding proves a passage is on the page, not that it was taken from the right part of it, which is why quotations for queue dates carry their section heading and row label rather than a bare date.

needsReview (string | null) records a field that could not be sourced and why — see states/connecticut.json, where the host that publishes the expedited-service document accepts no connection on any route tried, and every field is left unfilled rather than guessed.

Coverage

expedite is researched for every jurisdiction the collecting network can reach.

standardProcessing, completed 2026-08-09, stands as follows:

The false count is the headline, and it is worth understanding before consuming this field. Roughly two in five states sell speed and never say what the free lane costs in time. Iowa is the clearest case: it prices a five-business-day lane at $15 and publishes no baseline at all, so the ordinary lane is slower than five business days by a margin the state does not state. A false here is therefore a fact about the state's disclosure, and consumers should render it as "not published" rather than inferring any duration from it.

Each false is evidenced rather than assumed. The evidence is recorded in the record's notes and is usually one of four shapes: the state answers the processing-time question for a different service in the same document (Oklahoma answers it for apostilles, twice, and never for an entity filing); it answers the question in events rather than durations (Virginia lists which emails arrive, never when); it publishes an enumerated help corpus that simply has no such entry; or it repeatedly warns about delays from a baseline it never states (Hawaii).

Three records carry a statement with basis: null (Alabama, Kansas, New Hampshire). The schema permits it, but a consumer cannot tell from the field alone how to read the sentence. Assigning a basis to those three is the one known piece of tidying left in this namespace; no value is wrong.

Known dates that will move this data

Every record was read from its publisher on or before 2026-08-09 and carries its own lastVerified for the expedite half and its own observedOn for the standard half. Read those fields before trusting a figure; they are per record, not per repository.

Re-verification of the expedite half runs twice a year, in early October and early January. Those dates are not arbitrary: US states move filing fees on January 1, July 1 and October 1 almost exclusively, so a pass timed just after an effective date catches a year's changes while a monthly pass would mostly re-read unchanged pages. The standard half is not on that cadence and does not need to be — see Tier B below.

Beyond the routine passes, these are the specific dates already known to move this data:

Maintenance model

Two cadences, because the two halves decay at different rates.

Tier A — expedite, on the existing state rotation. When a state comes up in the normal verification batch, its expedite schedule is re-read from the agency's fee page alongside everything else being checked for that state. Changes here are rare and announced (a fee change follows a statute or a regulation), so the existing rotation is the right frequency and this adds one page per state to a visit that is already happening.

Tier B — standardProcessing, never claimed as current. A queue page that moves daily cannot be made accurate by checking it quarterly, so the schema does not pretend otherwise: the value is published as an observation with observedOn, and the honest consumer-facing rendering is "as observed on 2026-08-06", with sourceUrl for the live figure. Refreshing it on the state rotation is a bonus, not a correctness requirement.

Proposed machine checks, in the spirit of the existing gate — each one catches a failure a human reviewer reliably misses:

1. sourceUrl and every sources[].url resolves (a dead fee page is the first sign of a reorganised schedule).
2. expedite.offered: true implies tiers[] is non-empty; offered: false implies notes explains it. Silent emptiness is the failure mode that made restrictedWords ambiguous.
3. feeUsd and the feeUsdMin/feeUsdMax pair are mutually exclusive — a record may not carry both a point value and a range for the same tier.
4. standardProcessing.observedOn older than N days downgrades the record to stale in the published table rather than failing the gate. A stale observation that says so is fine; one that presents itself as current is not.
5. basis and the populated fields agree: queue-date populates queueAsOf*, stated-range populates *BusinessDays. This is what stops a queue date from being silently rewritten as a duration.

Checks 1–3 and 5 are cheap and deterministic. Check 4 needs a policy decision on N.

Deferred, on purpose — do not lose

Seven entitysearch records mention expedited service inside free-text *Notes fields (filingFacts.llcFeeNotes, filingFacts.nameReservationNotes, renewals.notes). Five of them only state that such a service exists, which cannot conflict with anything. Two carry an actual figure — Illinois (24-hour online service $250, paper expedited +$100, 10 business days) and Arizona (expedited $85) — and those two will silently disagree with this namespace the day either state changes its schedule.

Deliberately not acted on: the prose stays as written, and no cross-namespace check is added for now. The exposure is two records, the figures sit in explanatory notes rather than in fields a consumer reads as values, and nothing downstream renders them. Revisit if this namespace is ever published or consumed alongside entitysearch, in which case the cheap fix is a check that flags a dollar amount near "expedit" in those note fields when it disagrees with the state's processing-time record.

Records

states/ holds all 51 jurisdictions. Three carry no purchasable value and say so in needsReview rather than guessing: two are unreachable from the collecting network and one is readable in statute and dark at the agency. The table below is a selection, not the full list: it names the record that first forced each shape the model had to absorb, which is why a state appears here at all. States that arrived later and exercised a shape already covered are not listed.