justin/new-site
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
new-site/docs/dexit-readiness-assessment.md

17 KiB
Raw Blame History

Readiness: corporate orders + "move a company" (conversion / domestication)

Honest assessment as of 2026-06-09. Question: are we ready to take Nevada/Texas incorporation orders end-to-end (name search, accept into ERPNext, etc.), and the mechanics of moving a corp out of Delaware + annual report + EIN.

Short answer

  • New NV/TX formation orders - order intake + ERPNext now VERIFIED e2e, BUT live name search is BROKEN. The 2026-06-09 e2e harness (scripts/e2e-formation-order.mjs) confirmed: live order insert -> ERPNext customer -> Sales Order with the correct BUSINESS-FORMATION + STATE-FILING-FEE line items and totals ($254 NV LLC, $479 TX corp) -> DB linkage, all PASS for both NV and TX. However the name-search adapters silently fail (see below), so we cannot yet tell a customer whether their chosen name is available. The DEXIT page points at a contact form, not this checkout.
  • "Move a company" (DE -> NV/TX conversion/domestication): NOT built. There is no order type, no SKU, and no fulfillment for a conversion. This is the core of the DEXIT promise and is the biggest gap.
  • Annual report filing in the new state: NOT built as automation. There is an annual-report-filing slug, but it is wired to the trucking admin-assisted handler (MCS150UpdateHandler), not a corporate state-filing flow.
  • EIN: for a move you generally do NOT get a new EIN (see mechanics below); our ein_worker only obtains a NEW EIN, which is the wrong operation for a conversion.

So: do not turn on a "buy now" DEXIT checkout yet. Keep the page as a lead-gen "get my estimate" CTA (which it currently is) until the flow below is built + tested.

E2E test results (2026-06-09) and the name-search bug

Ran scripts/e2e-formation-order.mjs inside the api container against live prod (real DB + real ERPNext, no real Stripe charge, no real state filing).

PASS - order intake + ERPNext Sales Order (both NV and TX):

  • live formation_orders insert,
  • ERPNext customer find/create,
  • Sales Order created with BUSINESS-FORMATION + STATE-FILING-FEE line items, correct totals ($254 NV LLC = $179 + $75; $479 TX corp = $179 + $300),
  • formation_orders.erpnext_sales_order linkage written,
  • cleanup (cancel+delete SO, delete order row).

Bugs the harness caught and we fixed:

  • The formation Sales Order referenced ERPNext Items BUSINESS-FORMATION and STATE-FILING-FEE (and FOREIGN-QUAL-SINGLE/MULTI) that did not exist -> the SO creation was silently failing on every formation order. Created the Items.
  • entity_type check constraint requires lowercase (llc, corporation, ...).
  • The API's GET /states/:code/name-search called WORKER_URL/name-search, but the worker had no such route (404 -> silent fallback to stale entity_cache). Added a synchronous /name-search worker route, and fixed handle_name_search (both referenced a nonexistent search_name_sync).

FAIL (open) - live name search silently returns "unavailable" for everything. After wiring the route, a deliberately unique nonsense name still returns available=false with no similar names. Root cause: the NV state-portal adapter times out (Page.fill: Timeout ... waiting for locator("input[type=text], ...")) because the Nevada SOS / SilverFlume search page no longer matches the adapter's input selector, and search_name() swallows the exception and defaults to available=False. So:

  • We would wrongly tell customers an available name is taken (or never validate it).
  • This is a portal-scraping maintenance task: inspect the current NV (and verify TX) name-search DOM, update states/nv/adapter.py (and tx) selectors/flow, and make search_name() distinguish a real "taken" result from an adapter error (return an explicit error/unknown state, never a false "taken"). NOTE the adapter also MIS-PARSES on its happy path: via the route a unique name still returns available=false (the search page content does not match the adapter's "no results" phrases), so the fix must update both the input selector AND the results parsing. We did harden the error path: search_name() now returns available=None on a thrown adapter error. The harness re-run is the acceptance test.

Conclusion: the ERPNext/order plumbing is sound and verified; do not enable a self-serve formation checkout until name search is fixed (a customer must be able to trust the availability check), and the "move a company" flow is still unbuilt.

What already exists (the good news)

The corporate/formation machinery is real and reusable:

  • Checkout + order intake: api/src/routes/checkout.ts has order_type: "formation", builds a Stripe line item Business Formation (<state> <LLC|CORP>), and the formation_orders table carries stripe_session_id, payment_status, erpnext_sales_order, etc. ERPNext SO creation is wired for formation orders.
  • Name search: GET /api/v1/states/:code/name-search (24h cache in name_search_cache) -> calls the worker -> per-state adapter. TX uses the Comptroller Taxable Entity Search (free, no login); NV has an adapter too.
  • Filing automation: scripts/formation/ is a full subsystem - formation_worker.py polls formation_orders, states/tx/adapter.py + states/nv/adapter.py implement search_name / file_llc / file_corporation via Playwright (TX = SOSDirect, requires login + ASP.NET viewstate handling), plus ein_worker.py, operating_agreement.py, document_delivery.py, registered-agent via Northwest RA, and ~55 state adapters scaffolded.
  • The FormationOrder model carries entity name/alt, members, RA, addresses, shares_authorized, par_value, expedited, payment card (Relay virtual debit), and result fields (filing number, confirmation, documents).

What's missing for NEW NV/TX formation (smaller gap)

  1. E2E verification. The TX/NV adapters target live state portals (SOSDirect needs an account login; both are ASP.NET/viewstate + possible CAPTCHA). We have not confirmed a clean run recently. Need: a staged dry-run (name search -> formation_orders insert -> worker pick-up -> ERPNext SO -> filing in a sandbox or a real low-stakes filing) with screenshots, and CAPTCHA handling confirmed.
  2. ERPNext SO for formation exists in code; verify it actually creates the SO with the right items + state gov fee line (we hit a gap like this on the trucking compliance_batch flow - SOs weren't being created). Add NV/TX formation Items if missing (we created LLC-FORMATION / CORP-FORMATION recently).
  3. Pricing/SKU sanity: TX/NV LLC = $300 gov fee, Corp = $300; expedite +$25/$50. Our corp-formation / llc-formation catalog entries need gov_fee plumbed.

What's missing for "MOVE a company" (the big gap)

This is a different operation from formation. Real-world mechanics:

The legal mechanic (two paths)

A company changes its state of incorporation by either:

  • (A) Statutory conversion / domestication (preferred, cleaner): the entity re-domiciles. Delaware files a Certificate of Conversion to convert OUT (DGCL 266) and the destination state files a conversion/domestication in:
    • Texas: TBOC Ch. 10, Subch. C - "Certificate of Conversion" + new Certificate of Formation. The TX entity is a continuation of the DE entity (same legal person).
    • Nevada: NRS Ch. 92A.105+ "conversion"; file Articles of Conversion + new Nevada charter (NRS 78).
    • Florida: F.S. 607.11921+ conversion. Both DE-out and new-state-in filings are required. The entity keeps its identity, contracts, and history.
  • (B) Reincorporation merger (older method, what FG Financial used): form a new NV/TX subsidiary and merge the DE parent INTO it. Requires an Agreement and Plan of Merger + stockholder vote. More moving parts; still common.

Steps a real DEXIT order involves (none automated yet)

  1. Diagnose: pull the entity's current DE status, authorized shares (to estimate the franchise tax saving), good-standing, foreign qualifications.
  2. Board + stockholder approval: a board resolution and (usually) a stockholder vote/consent approving the conversion or merger. **This needs the client's counsel
    • it is NOT something we file.** Our role is to prepare the plan-of-conversion / plan-of-merger documents for their counsel to review and their board to adopt.
  3. Pay DE to leave: DE requires the franchise tax to be current before it will accept the Certificate of Conversion (you can't leave owing tax). So step 0 is often "file/pay the final DE franchise tax + annual report."
  4. File the conversion: Certificate of Conversion OUT of DE (DGCL 266) + Certificate of Conversion/Formation INTO the destination state. Both have fees.
  5. New registered agent in the destination state (recurring; we use Northwest RA).
  6. First annual report / state list in the new state (NV requires an Initial List
    • State Business License at formation/domestication; TX has the Public Information Report / franchise tax with the ~$2.47M no-tax-due threshold).
  7. Update downstream: foreign-qualification re-registration in states where the company operates (the domestication may need to be reflected), update the transfer agent / DTC, update EDGAR (state-of-incorporation on the next cover page), bank, etc.

EIN reality

  • A conversion/domestication generally KEEPS the same EIN - the IRS treats a mere change of state of incorporation (same entity continuing) as not requiring a new EIN in most cases. So our ein_worker (which obtains a NEW EIN) is the wrong tool for a move; for a conversion we typically do nothing with the EIN, or at most file a name/address change with the IRS.
  • A reincorporation MERGER into a new subsidiary can be different: if the surviving entity is genuinely new, the IRS may require a new EIN. This is a fact-specific, counsel-driven determination - we should not auto-decide it.
  • Net: EIN handling for a move is advisory + occasionally a name/address update, not the automated SS-4 flow we have.

Why we can't fully automate the move

Unlike a fresh formation, a conversion is counsel-gated (board/stockholder approval, plan-of-conversion review) and DE-clearance-gated (must be current on franchise tax). The honest product is admin-assisted: we prepare and file the state paperwork and set up RA + first annual report; the client's lawyer handles the corporate-approval documents. That matches how the DEXIT page is already written ("your counsel just reviews the board and stockholder consent").

Complication: the company has foreign qualifications in other states

This is common and important. A Delaware corp that operates in California, New York, Texas, etc. is "foreign qualified" (registered as a foreign entity / has a Certificate of Authority) in each of those states. When it domesticates DE -> NV/TX, every one of those foreign registrations is affected. Getting this wrong means the company is suddenly doing business unregistered in states where it operates - default judgments, loss of court access, penalties. So this is part of the core offer, not an afterthought.

What actually has to happen to the foreign registrations

After a conversion/domestication, the entity is the same legal person but its home (domestic) state changed. In each state where it was foreign-qualified:

  • The state where it is moving TO (say it domesticates to Texas but was foreign qualified in Texas): the foreign registration must be withdrawn/cancelled because the company is now a domestic Texas entity - you cannot be both foreign and domestic in the same state. (This is exactly why ~zero of our OTC sample were TX-incorporated even when TX-based: they were DE corps foreign-qualified in TX.)
  • Every OTHER state it was qualified in (CA, NY, FL, etc.): the foreign qualification generally stays in place but must be updated to reflect the new state of incorporation and (often) a new formation date / charter document. States differ:
    • Some accept an amendment to the foreign registration (file an amended Application for Authority / Statement of Change reflecting the new domestic state).
    • Some require you to withdraw the old foreign registration and re-file a new one from the new home state.
    • A handful treat the domestication as a non-event if the name + identity are unchanged, requiring only an informational update at the next annual report.
  • Name conflicts can surface: a name available to a DE corp as "foreign" in a state might collide on re-domestication; we should run name availability in each qualified state as part of the move.

Good news: we already have the building block

We have a working foreign-qualification capability:

  • SKUs foreign-qualification-single ($149 + state fee) and foreign-qualification-multi (discounted per-state), ForeignQualificationHandler that fans out per state, a state_registrations/foreign-qual schema (migration 066/073), and the same formation state-adapter pool. So re-qualifying or amending in N states reuses existing plumbing - we don't build it from scratch.
  • What's missing is the amend / withdraw modes (the handler today is oriented to new registration), and an intake step that asks "which states are you currently foreign-qualified in?" so we can fan the move out across them.

Product implication

The conversion offer should be multi-part and priced per state touched:

  1. Core domestication (DE-out + new-state-in) - the base fee.
  2. For each state the company is foreign-qualified in: an amend / re-qualify / withdraw line item (reuse foreign-qualification per-state pricing).
  3. Withdraw the now-redundant foreign registration in the destination state if one existed.
  4. Update the registered agent in each affected state where we maintain it.

This is also a revenue multiplier: a single DE corp qualified in 5 states is one domestication + ~5 foreign-qual amendments + recurring RA/annual-report in each. But it must be scoped at intake - we have to ASK for the list of states up front, estimate per-state, and disclose that government fees vary and are billed at cost.

Intake + data we must capture for a move

  • current domestic state (DE), destination state (NV/TX/FL), entity type
  • entity name + EIN (kept), current good-standing + franchise-tax status in DE
  • the full list of states where the company is foreign-qualified (and its DBA/ assumed names in each) - this drives the per-state fan-out
  • where it actually operates / has nexus (to advise whether to keep each qualification)
  • whether counsel is handling the board/stockholder consent (always yes)

Recommended build plan (generic corporate flow + a "move" capability)

Keep it generic, not DEXIT-specific:

  1. Catalog SKUs (in api/src/service-catalog.ts):
    • entity-conversion (move a company; admin-assisted; flat service fee + state gov fees billed at cost; destination state chosen at intake).
    • Confirm corp-formation / llc-formation carry per-state gov_fee.
    • annual-report-filing for corporate (today it points at the trucking handler).
  2. Order type: add order_type: "entity_conversion" to checkout + a from_state / to_state / entity_type intake, persisted in formation_orders (or a sibling table). Reuse the Stripe + ERPNext SO path.
  3. Fulfillment: a ConversionHandler (admin-assisted) that: (a) runs name availability in the destination state (existing name-search), (b) generates the plan-of-conversion + new-state charter draft for client/counsel, (c) queues the DE-out + destination-in filings for the formation_worker once the signed board/stockholder consent + DE good-standing are confirmed, (d) sets up RA + files the first annual report/state list.
  4. E2E test harness: a scripted run that does name search -> creates a paid test order -> verifies formation_orders row + ERPNext SO + worker pickup, with the actual state filing stubbed/sandboxed so we don't make a real filing during tests.
  5. Verify NV/TX formation e2e FIRST (smaller scope) before layering conversion on top, since conversion reuses the same filing + ERPNext + worker plumbing.

Bottom line

  • The page is fine to ship as lead-gen (estimate request), which is what it does.
  • We are not ready for a self-serve "buy a DE->NV/TX move" checkout. New NV/TX formation is close but unverified e2e; the conversion ("move") flow and corporate annual-report automation do not exist yet.
  • Next concrete step (if you want to proceed): verify NEW NV/TX formation e2e, then build the generic entity-conversion SKU + admin-assisted handler on the existing formation plumbing.