# 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:** mostly built, but **NOT yet verified e2e** and the
  DEXIT page does not point at this checkout (it points at a contact form).
- **"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.

## 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").

## 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.