What DocExtract Mega adds after extraction

Correction (2026-09-23): This post originally stated that identifier fields like invoice_number are silently rewritten (e.g., "INV-10O1" → "INV-1001") and that correction.applied means the audit array is nonempty. Both statements are outdated. The live Mega tier now emits identifier corrections as advisory-only entries: the original value is preserved in data, and the proposed correction appears in advisory: true and suggested: "" keys. correction.applied is true only when at least one change actually mutated data (before != after); advisory entries have before == after and do not set applied. The examples and guidance below have been updated to reflect current behavior.

Getting JSON back is only part of an extraction job. Your importer may need dates as MM/DD/YYYY, amounts as two-decimal strings, and one spelling of a vendor's name. A result can be valid JSON and still need that cleanup before it fits your system.

DocExtract's Mega plan (formerly called Business) adds a deterministic correction and normalization step after the model returns its result. Its current listing is $50 per month for 50,000 requests (reduced from $99/month on 2026-09-20), with a hard monthly request limit.1 The plan also has RapidAPI's separate bandwidth allowance and platform-fee terms; check the listing before subscribing.1

The Business guide has the complete request format. This post explains what the extra step does, and when you should still review its output.

Correction runs before your formatting rules

On eligible requests, DocExtract first checks selected extracted fields for recognizable OCR-style errors. A numeric total_amount of "21O.OO" can become 210.0. A date such as "2026/09/18" can become "2026-09-18". A recognized currency code such as "c4d" can become "CAD".

Identifier correction is advisory only. When a confused glyph sits between digits (for example INV-10O1), the original value is preserved in data and an advisory audit entry is emitted with advisory: true and suggested: "INV-1001". Prefixes such as INV, BOX, and RESTORE are preserved. An ambiguous token such as "I1l" is left alone with no advisory.

This prevents silent corruption of legitimate business codes that use letters deliberately (for example PO-1O5 region code O, AC-1B5 Bristol branch B, BL-2S9 sea freight S, LC-7I2 tranche I, AB-5I7 roman numeral I). Integrators should surface advisory entries for human review rather than auto-applying suggested.

These are rules over the model's extracted JSON. They do not scan an image, recover missing text, or establish that an invoice number is correct. Review important identifiers against the source document.

Choose the representation your importer needs

You can add a normalization object to the usual extraction request. It accepts field-specific date formats, numeric representations, and literal text replacements:

{
  "normalization": {
    "date_format": {
      "invoice_date": "US",
      "due_date": "ISO"
    },
    "numeric_format": {
      "total_amount": "CURRENCY",
      "line_items[0].unit_price": "NUMBER"
    },
    "text_substitute": {
      "vendor_name": {
        "from": "Ltd.",
        "to": "Limited"
      }
    }
  }
}

Paths start inside the response's data object. Use invoice_date, not data.invoice_date. A path such as line_items[0].unit_price addresses one array item; it does not apply to every line item.

A synthetic test of the deployed postprocessor produced these results. This isolates the correction rules; it is not a captured model-extraction response.

The invoice_number field shows "INV-10O1" in both columns because identifier correction is advisory: the original value is preserved and the proposed correction ("INV-1001") appears only in the audit's suggested field.

CURRENCY returns a string with two fractional digits. It does not convert between currencies, add a currency symbol, or check whether the amount is right. If your application needs a JSON number instead, choose NUMBER; use DECIMAL for a decimal string without forcing two decimal places.

Text substitution is an exact, case-sensitive replacement at one path. Replacing Ltd. with Limited can help with a known naming convention, but it is not fuzzy vendor matching or a database lookup.

Read the record of changes

The final values stay in data. A completed Business postprocessing pass also returns a correction object. Its changes array records the field path, value before and after the operation, method, and reason. Two optional keys exist for identifier advisories: advisory (boolean) and suggested (string). For example, this is the advisory audit entry for invoice_number from the synthetic test above:

{
  "path": "invoice_number",
  "before": "INV-10O1",
  "after": "INV-10O1",
  "method": "deterministic_ocr",
  "reason": "identifier OCR confusion suggested (advisory, not applied)",
  "advisory": true,
  "suggested": "INV-1001"
}

OCR-style repair runs first, so a field can have two entries: one for correction and another for your requested format. No-op rules do not create entries. Identifier advisories are created (with advisory: true and before == after) because they carry a proposed correction that was deliberately not applied.

There is one detail worth handling explicitly: correction.applied is true only when at least one change actually mutated data (before != after). Advisory-only entries (where before == after) do not set this true. A rejected normalization configuration still sets applied: true. Note: changes can be nonempty while applied is false (advisory-only entries are present but do not set applied); consumers should iterate changes checking the advisory flag rather than gating on applied.

Use your Mega subscription, not a tier header

Send requests through the RapidAPI endpoint using your subscriber key. RapidAPI supplies the trusted subscription information that DocExtract uses to enable Business features. Sending MEGA yourself, or adding normalization rules to a direct API-key request, does not grant Business access.

The correction step runs automatically for eligible requests. The normalization object is optional: omit it if you only want the built-in correction rules.

The larger quota does not remove the limits

The 16,000-character content limit and 64,000-byte request-body limit still apply. Normalization allows at most 20 field rules in a compact UTF-8 configuration of at most 2,048 bytes. The origin's existing rate limit also remains; the monthly quota is not a promise of a dedicated request rate.

Business uses the same extraction templates: invoices, resumes, meeting notes, contracts, and general text. It does not add PDF/image uploads, unlimited document length, a dedicated model, or an accuracy guarantee. Missing fields stay missing, and a rule that does not match an existing value can do nothing.

Use Business when you have a known destination format and want the cleanup rules beside the extraction call. Start with representative documents, validate the fields that matter to your workflow, and keep an eye on the audit rather than treating every successful response as ready to import.

Read the Business/Mega feature reference and examples, or return to the DocExtract quickstart.

Sources

[1] DocExtract RapidAPI pricing (live, 2026-09-18) (accessed 2026-09-18).