AI Document Intelligence & Data Extraction

The pain

Your AP clerk opens a PDF, reads the vendor name, invoice number, date, currency, subtotal, tax and each line, then retypes it into a Vendor Bill. A contract arrives by email and someone has to find the renewal date, notice period and price escalation clause before it can be tracked. A packing slip is scanned, filed in the File Cabinet, and never reconciled against the Item Receipt. Employees photograph receipts and the expense report gets keyed from memory a week later.

Every one of those documents already contains the data NetSuite needs. The cost is not the data — it is the human sitting between the PDF and the record, and the errors that human introduces at 4pm on the last day of the month.

What ECOSIRE builds

We build a document intelligence pipeline inside your NetSuite account. It is not a hosted portal you log into separately: documents land in NetSuite, get parsed, and become NetSuite records with an audit trail.

Ingestion

Documents enter through whichever channels you actually use. We wire a RESTlet endpoint for programmatic push and for a scan-to-NetSuite step, a File Cabinet folder watcher driven by a Scheduled Script, and an inbound email capture path so an AP mailbox can forward straight into the queue. Every inbound document is stamped onto a custom record — typically customrecord_eco_doc_intake — holding the source, the File Cabinet file ID, the received timestamp, the detected document type and the processing state.

Extraction

A Map/Reduce script drives extraction so a thousand-page backlog and a single invoice use the same code path. The map stage calls your chosen OCR and language-model endpoint via N/https, using credentials you own and hold in a Secrets entry — we never route your documents through ECOSIRE infrastructure. The reduce stage writes the parsed result as structured JSON onto the intake record and creates one child line record per detected document line.

Extraction is configured per document type against a field map you approve during scoping: vendor identity, document number, document and due dates, currency, subtotal, tax, total, PO reference, and line-level item, description, quantity, rate and amount. For contracts we extract term start and end, renewal and notice dates, governing entity and named commercial values into a contract custom record with reminder-ready date fields.

Matching into NetSuite

Extraction is worthless if it cannot resolve to real records. We build the resolution layer explicitly:

• Vendor resolution against the Vendor record using tax ID, remit-to email domain, bank detail and name similarity, with a confidence score written to the intake record.
• PO matching against open Purchase Orders by PO number, then by vendor plus amount tolerance, then by vendor plus item overlap.
• Item resolution using vendor part number on the Item record, item aliases, and a learned mapping custom record that remembers every correction a human makes.
• Segment defaulting for Subsidiary in OneWorld, Department, Class, Location and any custom segments you use, sourced from the PO, the vendor default, or a rule table.

Review and posting

Nothing posts silently. A Suitelet review screen shows the source PDF side by side with the extracted fields, each field carrying its confidence and a click-to-locate highlight. Fields above your configured confidence threshold are pre-accepted; anything below is flagged for a human. On approval, a User Event and server-side record creation produces the real transaction — Vendor Bill, Expense Report, Item Receipt, or a contract custom record — with the source file attached and the intake record linked both ways.

Corrections are captured, not discarded. Every human edit updates the learned mapping records, so vendor-specific quirks stop being re-corrected after the first pass.

Controls and routing

SuiteFlow handles what happens after extraction: three-way match variance routing, approval by amount band, hold on duplicate invoice number per vendor, and exception queues for unresolvable vendors. Role and permission design is part of the build — the reviewer role sees the queue and the source document, and posting rights follow your existing AP approval matrix rather than a new one.

Reporting

We ship saved searches and a dashboard portlet covering throughput, straight-through processing rate, average confidence by vendor, exception ageing, and the documents that consumed the most human time — so you can see which vendors are worth a template refinement.

Who this is for

Finance teams processing enough vendor bills, expense receipts or supplier documents that keying is a staffed activity rather than an incidental one. It fits companies running OneWorld with several subsidiaries and currencies, distributors reconciling packing slips against receipts, and any organisation whose contract dates live in a shared drive instead of a system.

It is not a fit if your document volume is a handful a week, or if your documents are handwritten with no consistent structure — we will tell you that on the scoping call rather than after the invoice.

How delivery works

1. Scoping call. We look at your actual documents — a real sample set, not a description — plus your NetSuite edition, OneWorld status, AP approval flow and the segments you post to. We identify which document types are viable and what the confidence threshold should realistically be. 2. Fixed quote. You get a written scope: document types, field maps, target record types, matching rules, review UI, routing, and what is explicitly out of scope. The price is fixed against that scope. 3. Build. Development happens as an SDF project against your sandbox account. You get progress checkpoints, not a black box. 4. Install in test. The bundle is deployed to sandbox first. You run your own documents through it. We tune field maps and matching rules against your real data during this phase — this is where the accuracy actually gets earned. 5. Install in production. Once you sign off in sandbox, we deploy to production as an unmanaged bundle or SDF deployment, run a controlled parallel period on live documents, then cut over. 6. Support. A defined support window follows go-live for defect fixes and extraction tuning, with a handover session so your admin can add document types and adjust rules without us.

You own the source. The scripts, custom records, saved searches and the SDF project are yours, unmanaged, readable and editable by your own team or any other developer you choose.

Honest limits

Extraction accuracy depends on document quality and consistency. Clean digital PDFs from a repeat vendor reach high straight-through rates quickly; poor scans, unusual layouts and first-time vendors need review passes before they settle. We build the review path precisely because no extraction system is right every time, and posting an unreviewed guess into your general ledger is worse than keying it.