Extracting Order Data with AI: Missing Fields, Units, and Checks Before Import

Let's discuss your project →

This lab shows how to turn free-form order text into structured data without inventing missing values, without overwriting source quantities, and without sending a record to import before it passes basic checks. OpenAI’s Structured Outputs documentation describes schema-bound JSON, optional values represented with null, and the need to handle refusals or incomplete outputs in the application layer. See Structured Outputs and the Responses API version of Structured Outputs.

If this workflow later needs to connect to an ERP, CRM, ecommerce platform, or another internal system, the most relevant internal services are AI and responsible automation, Custom software and integrations, and, for scoping the integration itself, How to Brief an Adobe Commerce Integration: Data, Events, Retries, and Acceptance Criteria.

What you will end up with

At the end of this guide you will have a small, repeatable lab that produces:

  • a minimal JSON schema for order extraction;
  • a reusable prompt that forbids invented defaults;
  • three complete simulated orders: one normal, one with an explicit conversion, and one with missing data;
  • expected outputs for each case;
  • a pre-import decision log that tells you whether to import, stop, or send the record to human review.

The examples are simulated. They are not client cases, operational tests, or real business outcomes.

Who this is for, tools, and prerequisites

Audience

  • operations and back-office teams that retype order data between systems;
  • IT, no-code/low-code, and development teams connecting AI to an ERP, CRM, or order-management workflow;
  • editorial or training teams that need a reproducible AI lab rather than a conceptual overview.

Tools

  • a text editor or test workspace where you can paste input and inspect output;
  • an AI model or workflow that can return structured JSON;
  • a simple log sheet, spreadsheet, or ticket template for review notes;
  • your own business rules for what blocks import.

Prerequisites

  • know which fields are mandatory in your process;
  • know whether your downstream system expects source units, converted units, or both;
  • decide in advance who can approve ambiguous records.

What not to assume

  • do not assume the AI can infer a missing SKU from context;
  • do not assume a valid JSON object is automatically safe to import;
  • do not assume a quantity can be converted without an explicit rule.

1. Define the extraction contract

Work in a test file or sandbox first, not in the live ERP or order system. The goal of this step is to lock the shape of the data before you run any extraction.

Minimal JSON schema

Use this base schema for the lab:

{
  "order_id": "string",
  "sku": "string | null",
  "quantity": "number | null",
  "unit": "string | null",
  "missing_fields": ["string"]
}

Contract rules

  • order_id is required.
  • sku, quantity, and unit may be null if they are absent or not reliable.
  • missing_fields must list only fields that are truly missing or not recoverable with confidence.
  • Never replace a missing value with 1, 0, unknown, n/a, or an empty string.
  • If you later need a derived quantity, keep it separate from the source quantity. Do not let a converted value overwrite the original input.

Why this matters

A schema alone does not solve the business problem. It only prevents the AI from drifting into free text. The actual control comes from the rule that a record is not importable until the source data, unit interpretation, and missing-field handling are all consistent.

If your system cannot store null cleanly, fix the pipeline first. Do not use a fake default to work around a missing value.

2. Paste the prompt and keep the output shape strict

Work in the same sandbox and use one prompt for all three test cases. The prompt below is intentionally narrow: it tells the model to return only JSON, to keep missing values as null, and to avoid any extra explanation.

Reusable prompt

You are an order-data extractor.

Return only valid JSON that matches the required schema.

Rules:
1. Do not invent any missing value.
2. If a field is absent, use null and add the field name to missing_fields.
3. Never replace missing values with 1, 0, empty strings, or implied defaults.
4. If you find an explicit conversion, do not overwrite the source quantity: record the conversion only if the workflow supports it.
5. Keep order ID, SKU, quantity, and unit separate.
6. If the text is ambiguous or incomplete, flag the missing fields.
7. Do not add comments, explanations, markdown, or any text outside the JSON.

Required schema:
{
  "order_id": "string",
  "sku": "string | null",
  "quantity": "number | null",
  "unit": "string | null",
  "missing_fields": ["string"]
}

What to check before moving on

  • the prompt does not ask the model to guess;
  • the prompt does not let a missing field become a default;
  • the prompt does not ask for extra prose;
  • the prompt can be reused for every order in the lab.

If the model still returns extra text, shorten the surrounding instructions and keep the output request explicit. If it still drifts, the issue is usually the control layer, not the order text.

3. Run the simple order

Work in the same test file, but use the first simulated order alone. This is the normal case: one order ID, one SKU, one quantity, one unit.

Simulated order input

Order ORD-1001
SKU: BIC-24
Quantity: 15
Unit: pieces
Notes: standard delivery.

Expected output

{
  "order_id": "ORD-1001",
  "sku": "BIC-24",
  "quantity": 15,
  "unit": "pieces",
  "missing_fields": []
}

Result to observe

  • the order ID is preserved exactly;
  • the SKU is extracted without alteration;
  • the quantity stays numeric;
  • the unit is retained as written;
  • missing_fields is empty.

If it diverges

  • if the model adds a field, the schema is too loose or the prompt is not strict enough;
  • if the quantity becomes a string, normalize the output parser before import;
  • if any field is missing here, do not proceed to the harder cases until the configuration is fixed.

A normal order should be boring. If the simple case fails, do not treat the result as usable just because the JSON is syntactically valid.

4. Run the explicit conversion order

Work in the same sandbox and test the order that contains a conversion. This case is important because it forces you to separate the source quantity from the derived quantity.

Simulated order input

Order ORD-1002
SKU: PEN-BOX12
Quantity: 2 boxes of 12 pieces
Unit: boxes
Note: each box contains 12 pieces.

Expected output

{
  "order_id": "ORD-1002",
  "sku": "PEN-BOX12",
  "quantity": 2,
  "unit": "boxes",
  "missing_fields": []
}

What the conversion means

The explicit conversion is 2 boxes × 12 pieces = 24 pieces, but that figure must stay outside the source payload unless your downstream process has a separate derived field and a clear rule for storing it.

Suggested review note

Source quantity preserved: 2 boxes
Explicit conversion declared: 24 pieces
Import decision: hold for review if the receiving system expects pieces instead of boxes

If it diverges

  • if the model returns 24 in quantity, it has overwritten the source value;
  • if the unit disappears, the output is no longer traceable;
  • if the conversion is not explicit in the text, do not invent it.

This is the key operational idea: source data and derived data are not the same thing. Keep them separate, or the import will look correct while being wrong.

5. Run the missing-field order

Now test the failure case. The purpose here is to confirm that a missing field stays missing and does not get filled with a guess.

Simulated order input

Order ORD-1003
Quantity: 8
Notes: store pickup.

Expected output

{
  "order_id": "ORD-1003",
  "sku": null,
  "quantity": 8,
  "unit": null,
  "missing_fields": ["sku", "unit"]
}

Result to observe

  • the missing SKU is represented with null, not guessed;
  • the missing unit is represented with null, not guessed;
  • the present quantity remains 8;
  • missing_fields lists only the absent fields.

If it diverges

  • if the model invents a SKU, block the workflow immediately;
  • if the model inserts a placeholder unit, treat that as an error;
  • if the model leaves missing_fields empty, the extraction contract is not being enforced.

Extra edge case: numeric separators

If the source text contains numbers like 1,500 or 1.500, do not guess whether the separator means a decimal or a thousands marker. Use a locale rule that is already agreed in the process. If no rule exists, the record must stop for review.

Extra edge case: non-standard units

If the text uses abbreviations such as ctn, pkg, or another internal shorthand, only map them if your team has already approved that mapping. Otherwise the unit stays null and the record is not ready for import.

6. Add numeric-separator and unit checks

Work in the validation layer, not in the extractor. Extraction answers the question “what does the text say?”; validation answers the question “can this be imported?”

Validation checklist

Check Who verifies it Expected outcome
order_id present system mandatory
sku present and traceable system or operator mandatory
quantity numeric system mandatory
unit recognized system or operator mandatory or mapped
conversion explicitly declared operator note it separately
numeric separator unambiguous operator if not, stop
missing fields listed correctly system null plus missing_fields

Two practical rules

  1. If the record depends on a conversion, the conversion must be explicit in the source text or in a separately approved mapping.
  2. If a number can be read in two ways, the process must stop rather than choose silently.

Example decision table

ORD-1001 -> import allowed
ORD-1002 -> review only unless a derived quantity is formally accepted
ORD-1003 -> block import

This is where an AI workflow becomes operational instead of merely impressive. A syntactically correct output is not enough if the business rule says the record is incomplete.

7. Decide whether the record can be imported

Work in the review log or approval step. The goal is to make the decision visible, reproducible, and easy to audit later.

Reusable review template

Date:
Case ID:
Input source:
Extraction result:
Missing fields:
Conversion note:
Validation result:
Import decision:
Reviewer:
Comments:

Filled example: valid case

Date: 2026-10-14
Case ID: ORD-1001
Input source: simple order text
Extraction result: complete JSON
Missing fields: none
Conversion note: none
Validation result: passed
Import decision: allowed
Reviewer: operations lead
Comments: source and output match exactly

Filled example: rejected case

Date: 2026-10-14
Case ID: ORD-1003
Input source: order text with missing SKU and unit
Extraction result: sku = null, unit = null
Missing fields: sku, unit
Conversion note: none
Validation result: failed
Import decision: blocked
Reviewer: operations lead
Comments: do not invent values; send for human follow-up

Acceptance criteria for import

A record can move forward only if all of the following are true:

  • the source values are present and readable;
  • any conversion is explicit and approved;
  • no field is silently invented;
  • numeric formatting is unambiguous;
  • the validation log says who checked the record and when.

If your process also needs a derived unit such as pieces, store that in a separate controlled field or a separate review step. Do not let the AI quietly replace the source quantity with the converted one.

8. Troubleshooting and final acceptance check

Work in the same sandbox and use this section when the outputs do not match the expected results.

Common issues and fixes

Problem: the model fills missing data with fake values

  • Fix: tighten the prompt so it explicitly forbids defaults.
  • Fix: reject any output where a missing field is not null.
  • Fix: treat missing_fields as mandatory evidence, not a note.

Problem: the conversion overwrites the source quantity

  • Fix: keep the source quantity as the primary value.
  • Fix: record the converted value separately, if your process allows it.
  • Fix: do not let downstream import rules accept a derived value as if it were the original order.

Problem: the unit is not recognized

  • Fix: add an approved mapping table before production.
  • Fix: if no mapping exists, stop the record.
  • Fix: do not guess unit abbreviations from habit.

Problem: 1,500 is read differently by different people

  • Fix: define one locale rule for the pipeline.
  • Fix: if the source language or market varies, make the rule explicit in the validation layer.
  • Fix: do not let the model decide the separator meaning on its own.

Problem: output is incomplete or refused

OpenAI’s Structured Outputs documentation notes that refusals or incomplete outputs can happen and must be handled by the application, not ignored. See Structured Outputs and Structured Outputs — Responses API.

  • Fix: treat incomplete output as non-importable.
  • Fix: send the case back to a human reviewer.
  • Fix: log the failure rather than forcing the record through.

Final acceptance check

Before you call the lab complete, repeat the same three-case sequence in order:

  1. simple order;
  2. explicit conversion order;
  3. missing-field order.

The lab passes only if:

  • the simple order imports cleanly;
  • the conversion case preserves the source value and does not auto-overwrite it;
  • the missing-field case stays blocked;
  • no absent value is invented;
  • the review log explains each decision clearly.

If you need to move from a lab to a production flow, keep the conversation on process, validation, and integration design. That is the point where AI and responsible automation, Custom software and integrations, and How to Brief an Adobe Commerce Integration: Data, Events, Retries, and Acceptance Criteria become relevant.

If you want to align permissions and access boundaries before connecting systems, Integration permissions: a practical check of least privilege is a useful companion read.

If you want to turn this into a governed production workflow, describe the process you want to improve.

Sources