NOCA.AI: purchase orders, invoices and documents into Salesforce, NetSuite and Priority ERP

What NOCA.AI is and when it fits

NOCA.AI is a no-code platform for building AI-driven processes: document intake and reading, forms, bots and automation flows that connect to an organization's core systems. Its strength is speed: you can get to a working process against Salesforce, NetSuite or Priority ERP without writing everything from scratch.

A NOCA.AI flow is built from steps: a trigger (email, upload, form or API call), AI steps that classify and extract, conditions and business rules, and connector steps that read from or write to the target system. Each step can be inspected and changed without redeploying code.

CloudX is a certified NOCA.AI partner. We use it where it is strongest: turning documents that arrive from outside (purchase orders, invoices, service documents) into clean records in your system.

NOCA.AI fits when most of these are true:

• Documents arrive in volume, by email or upload, in inconsistent formats (PDF, Excel, scans).
• Someone in the organization retypes the data into a system today.
• The target is a system with a proper API: Salesforce, NetSuite, Priority.
• You need a process you can change quickly, without a full development cycle for every business-rule change.

For heavy bulk processing, or a process that lives entirely inside one system, we combine NOCA.AI with code or the system's native tools, so each part sits in the tool that suits it.

What we build with NOCA.AI

Purchase order intake from email into Priority and NetSuite, without manual entry

A customer sends an order as PDF or Excel. The flow classifies it as a new order, an update or a cancellation, extracts the data and creates or updates the order in Salesforce, NetSuite or Priority. Nobody in sales or operations retypes a line.

For intake into Salesforce and NetSuite, an Apex Email Service receives the email and stores the attachments as Salesforce Files on an intake record. A Queueable job sends one document at a time to the NOCA.AI flow through a Named Credential, and the result creates or updates the order, so calls to NetSuite stay within its concurrency limit.

Order intake into Priority

Orders are written to Priority through its REST (OData) API with a dedicated API user, as a sales order with its lines, so Priority's own validations and pricing still apply to every order.

AI invoice reading, beyond OCR

The flow extracts line items from supplier invoices in Hebrew and English, including delivery note, SKU, quantity and price, and checks them against what already exists in the system before anything is written.

Service documents into Salesforce

External documents such as referrals or reports are read with AI and the information goes into the right Salesforce records, with handling for duplicates and problematic ID values.

Forms, payments and interfaces

• A donation flow connected to a payment terminal that updates the donor record. Card details are entered and processed only on the payment provider's side, and only the transaction reference, amount and status are written to the donor record, so no card data is stored in Salesforce or in the flow.
• A flow that receives an ID number or phone number from an external system, finds the record in Salesforce and returns the data as JSON. Every caller authenticates with a dedicated key, the response holds only a fixed list of fields, and every request is logged, so a phone number alone cannot be used to browse records.
• A candidate portal with several forms (questionnaires, medical information, consent, file uploads) and a progress bar, built as a demo that shows a candidate completing every step in one place.

Lessons from real document extraction work

Most of the difficulty in document intake is not the model. It is the details. These are things we learned on processes running in production:

Describe the shape of the value, not its position. On Hebrew and English invoices, a prompt that says "the third column of the table" breaks as soon as a supplier changes its template. A prompt that describes what the value looks like, with examples, holds up much better.

Product matching needs an order of precedence. For order intake into Priority we built a tiered lookup: internal SKU first, then the customer's SKU, and only then a generic SKU, with the matched SKU saved in the line description so it can be reviewed.

Price and date are business rules, not extraction. A price check within a defined tolerance and delivery-date rules are what turn an extracted order into an order you can release. Those rules belong in the spec, written down clearly.

Multiple files and dirty data. An email with both a PDF and an Excel of the same order, IDs with hidden whitespace, duplicate rows inside one file: each of these shows up in real documents, and each has explicit handling in the flows we run.

Limits of the target system. NetSuite limits concurrent requests per account, according to its service tier and SuiteCloud Plus licenses. When several orders for the same customer arrive together, requests are rejected or collide on the same record. We serialized the calls on the Salesforce side and added retries for rejected requests.

Not everything needs AI. When a document arrives in a fixed structure, plain parsing is cheaper and more stable. AI goes where there is real variation.

Business problems this solves

AI reading differs from template-based OCR: there is no fixed template to set up per supplier, because values are recognized by what they mean, not by where they sit on the page.

• "A sales rep types every purchase order by hand, and our largest customer emails orders, updates and cancellations every day."
• "Orders land in Priority with wrong prices and we only find out at invoicing."
• "Referral documents arrive as PDFs and someone copies the details into the Salesforce file."
• "We cannot tell whether an order update was already handled, or captured twice."

What a good intake flow looks like, step by step

An intake flow that holds up over time is built in layers, not as one big prompt. This is how we build it:

1. Capture. The email is received, the original file is stored next to a dedicated record, and every email gets a status, so you always know what arrived and what happened to it.
2. Classify. New order, update to an existing one, or cancellation. A mistake here creates duplicates, so classification is also checked against what already exists in the system.
3. Extract. Read the data from the document: customer, order number, lines, quantities, prices and dates.
4. Match. Find the customer and products in the target system using a fixed order of precedence.
5. Validate. Price within tolerance, valid delivery date, required fields present. Whatever fails stays for a person to review.
6. Write. Create or update the record in the target system, at a pace the system can handle.

People stay in the loop

The goal is not to remove the team from the process, but to remove the typing. A document the flow is unsure about does not slip in with a guessed value. It is flagged, kept with its original file and waits for approval.

The team moves from typing every order to reviewing only the exceptions. That is also where new rules surface: an exception that keeps repeating is usually a rule waiting to be written down.

What it looks like: from an emailed order to a record in Priority

In a typical case, an organization receives orders every week from a handful of large customers, each in a different template. Someone in operations opens every email, looks up the products in Priority and types, and when a customer changes a quantity, the update can get missed.

In a project like this we start with the customer that sends the most orders, define the rules with them, and add customers one by one. Each new customer brings its own edge cases, and moving gradually folds them into the rules before the next customer joins.

What to prepare before you start

• 20-30 real documents of each type, including ones that caused problems.
• The rules your team applies today from memory: when a price counts as wrong, how urgent orders are handled, what to do when a product cannot be matched.
• A picture of the scope: how many documents arrive each month, from how many senders, and whether one person knows all the rules or they are spread across several.
• A sense of what a mistake costs: an order entered at the wrong price, or an order that never got in.
• Access to a test environment of the target system and an integration user.
• A contact on the team who knows the documents and can approve results.

When customer and product data in the target system is clean, automated intake is more accurate, so we check it at the start of the project. Where needed, we begin by cleaning up customers and SKUs in the target system.

How a project runs

1. Collect samples. We ask for real documents, including the difficult cases: scans, duplicate files, unusual suppliers.
2. Define the rules. What identifies a customer, what identifies a product, what happens when a price is out of range, when an order is an update and not a new one.
3. Build against a test environment. The flow runs against a sandbox of the target system.
4. Run on real documents. We compare the output to what a person would have entered, and fix.
5. Go live with support. New supplier templates and edge cases are folded into the rules as they appear.

Timeline depends on scope: how many document types, how many systems and how many business rules. A focused flow for one document type into one system is usually a matter of weeks, and a process serving several suppliers and several systems takes longer.

Choosing a partner: what to ask

• Can they show a document intake process running in production, not just a demo?
• What happens to a document the flow could not read? Is there a queue for manual review?
• Do they know your target system in depth (Salesforce, NetSuite, Priority), including its limits?
• Do they design the full process, including the parts that belong in code or in the ERP?

NOCA.AI vs alternatives

In practice we combine them. In the purchase order intake into Salesforce and NetSuite, intake and throttling were built in Apex, and classification and reading in NOCA.AI.

The split is deliberate. Salesforce is good at receiving email, storing files and pacing writes, because it is the system of record. NOCA.AI is good at reading an inconsistent document and deciding what it is. When each part sits in the tool that suits it, faults are easier to trace and one part can change without breaking the rest.

Matching the tool to the process

Before we build, we check which tool fits each part of the process: NOCA.AI, code in Salesforce, an integration platform or an app builder. We test new tools against the client's real systems and data, including details such as the stability of integration IDs, before we recommend them. That way the process that goes live sits on the tool that will hold it over time.

Why CloudX

• Three target systems in production: Salesforce, NetSuite and Priority.
• Matching rules that hold up: tiered SKU lookup, price tolerance and delivery-date rules written into the spec.
• Built for system limits: throttled intake that prevents NetSuite record locks.
• Hebrew and English documents: prompts that describe the shape of a value, not its position in a table.
• Salesforce depth behind every flow: the flow fits your data model and permissions, as part of a wider Salesforce implementation.

Want to check whether your documents are a fit for automated intake? Talk to us.