> For the complete documentation index, see [llms.txt](https://developer.emporix.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.emporix.io/partner-library/emporix-components/order-intake.md). # Order Intake Order Intake transforms unstructured purchase orders received by email into validated sales orders in your commerce and ERP systems. It automates extraction, validation, and routing so operators spend less time on manual entry and more time resolving exceptions. The value stream works with the [Order Intake Cockpit](https://developer.emporix.io/order-intake-cockpit/), where order managers can work on the emailed purchase order documents, monitor processing status, and complete orders that need review. AI Agents help in interpreting incoming content, extracting order details, validating them against your catalog and business rules, and routing exceptions for user approvals.

Autonomous Order Intake component in the Partner Library — Autonomous Order Intake in the Partner Library

## Key features and benefits | Feature | Description | | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Automated data extraction** | Order data is captured using AI-based parsing from emails and PDF attachments, ensuring consistent extraction across varying formats and reducing manual entry errors. | | **Validation and exception routing** | Extracted data is validated against predefined business rules, including customer identity, product availability, and pricing. Only incomplete or inconsistent orders are routed for review, with full context for resolution in the cockpit. | | **Order Intake Cockpit** | A dedicated interface for uploading documents, tracking extraction and validation status, correcting issues, and submitting approved orders. | | **Multi-channel intake** | Processes orders from incoming emails with attachments and from PDF uploads initiated directly in the cockpit. | | **Customer, product, and price validation** | Validates customers by ID or email, checks catalog availability per line item, flags unknown or out-of-stock products, and confirms pricing before order placement. | | **Product substitution suggestions** | When products are out of stock, the process can search for alternatives and generate suggestions so operators can update the order in the cockpit before submission. | | **ERP and commerce integration** | Validated orders are transferred into connected systems through APIs, eliminating duplicate manual entry. | | **Scalable, real-time processing** | Orders are processed as they arrive, supporting higher volumes without proportional increases in manual effort. | ## Business use cases The following use cases are examples of typical business scenarios, your implementation may differ based on project requirements.


	Processing email-based purchase orders	A buyer sends a purchase order by email with a PDF attachment. The value stream classifies the message, extracts line items and delivery data, validates the customer and products, and creates a sales order—routing only mismatches to an operator in the cockpit.
	Uploading document-based orders in the cockpit	An order manager receives a PO as a PDF and uploads it through the Order Intake Cockpit. The system extracts and validates the document, surfaces any missing customer or product data for correction, and submits the order once approved.
	Onboarding new customers from incoming orders	When an order references a customer that is not yet in the system, the process attempts automatic customer creation from available address data. If information is insufficient, the case is flagged in the cockpit for manual completion before the order proceeds.
	Resolving catalog and availability exceptions	Products that cannot be identified or are out of stock are flagged for review. Operators use cockpit document management to apply substitutions or skip lines, then submit the order without re-entering data in the ERP.

## Process flow The process begins when an operator uploads an order document in the Order Intake Cockpit, or when a new email containing an order is received. When either condition is met, the process starts and subsequent steps execute. Additional filters can limit which uploads start the process. For example, restricting the media (document) asset trigger to files linked to order intake data. The system collects attached documents and intake metadata, then AI-based components interpret the input, extract order details, and validate the resulting normalized order model. If validation succeeds, the order is transferred to connected systems. If validation fails, an exception is created for review and resolution in the cockpit. ### Document intake and extraction After a trigger fires, a conditional step evaluates the media asset type from the payload. When the type is a Binary Large Object (`BLOB`), the uploaded file is prepared for downstream extraction and validation. When the type is `null`, the process continues on the default path without additional file handling. Both paths merge into customer, product, and price validations. AI components interpret the content and extract customer details, line items, quantities, pricing, purchase order numbers, and delivery data into a normalized order model aligned with your system requirements.

Order Intake value stream from document triggers through customer, product, and price validation — Document intake and extraction steps in the Order Intake value stream

### Customer, product, and price validation To place the order, the data must include customer, shipping and billing addresses, and product and price data for all line items. **Customer validation** runs using identifiers in the payload. If no customer data is present, validation cannot continue. If a customer ID is provided, validation runs by ID first; if that fails and an email is available, the process retries by email. When no match is found, the process can create a new customer from available address data or require manual input in the cockpit. **Product validation** checks each line item against the catalog and availability. Items are grouped as available, not found, or out of stock. Unknown products are flagged for review; out-of-stock items can receive alternative suggestions from a RAG database for operator selection in the cockpit. **Price validation** requires a valid price for each product in scope. Missing prices are marked accordingly so operators can resolve them before submission. ### Order creation and cockpit approval Once validation conditions are met, the process matches prices, prepares a cart from the validated order data, and reaches an order form submission step that acts as the approval checkpoint. In the Order Intake Cockpit, operators review processing results, for example missing customer details or product substitutions. They manage corrections in the document view, and submit the order when ready. After order approval in the cockpit, the process creates the order in Emporix. The resulting sales order is visible in the cockpit and in the Management Dashboard.

Order Intake value stream from validated data through cart preparation, cockpit approval, and order creation in Emporix — Order creation and cockpit approval steps in the Order Intake value stream

{% hint style="info" %} Implementations of the process are tailored to each project to reduce manual effort, accelerate processing, and keep incoming order data consistent and reliable. For cockpit usage details, see the [Order Intake Cockpit](https://developer.emporix.io/order-intake-cockpit/) guides. To enable this functionality, contact the [Emporix Sales Team](mailto:sales@emporix.com). {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://developer.emporix.io/partner-library/emporix-components/order-intake.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.