Use case · Documents and finance
Supplier invoices into NetSuite or QuickBooks Online — no manual entry
A workflow watches the AP mailbox. Every attachment goes to an IntelliDocs stream described in plain language — vendor, tax ID, date, line items, totals — and comes back as JSON. The workflow matches the vendor and the PO, checks totals, and creates the bill through the accounting system's API. Anything with a field that fails validation or a mismatch goes to a person as an approval card; the rest posts without anyone opening the PDF.
- Who it is for
- Finance teams receiving a few hundred to a few thousand supplier invoices a month as PDF attachments, portal downloads or XML (CFDI, NF-e, DIAN), posting them into NetSuite, QuickBooks Online, Xero, Siigo or Alegra.
- Systems involved
- Outlook / GmailIntelliDocsNetSuite · QuickBooks Online · Xero · Siigo · AlegraSlack / Teams approvalsGoogle Sheets or AW Tables (exceptions log)
How the run goes
5 steps · logged per run
- Trigger01
New email with attachment
AP mailbox, shared inbox or SFTP drop
- Document02
IntelliDocs extracts fields
Vendor, tax ID, date, lines, totals
- Agent03
Validate and match
Vendor lookup, PO match, totals, duplicates
- Person04
Approve exceptions
Slack / Teams card, 24h timeout
- System05
Bill created
NetSuite / QBO / Xero / Siigo / Alegra
How it runs, step by step
- 1
The trigger is the AP inbox. Each email with a PDF, image or XML attachment starts a run; the email body and sender become context for the agent, which is how a "please find attached the corrected invoice" ends up replacing, not duplicating, the first one.
- 2
The attachment goes to an IntelliDocs Document Stream. The stream is a description, not a template: "supplier invoices; return vendor name, tax ID, invoice number, date, due date, currency, line items with description, quantity, unit price, net, tax, total". Handwritten notes on the invoice are read too. XML e-invoices skip the OCR step and are parsed directly.
- 3
A workflow step validates the result: the vendor is looked up in the accounting system by tax ID, line totals are recomputed, the invoice number is checked against bills already posted, and a PO is matched when the vendor uses them. Each check writes a reason to the run log.
- 4
Clean invoices are posted as bills through the accounting system's API, with the PDF attached and the run ID in the memo. Anything else — field that fails validation, unknown vendor, total mismatch, possible duplicate — becomes an approval card in Slack or Teams with the image and the extracted fields side by side. The approver fixes a field or rejects; the workflow continues with the answer recorded.
- 5
A daily digest lists what was posted, what was approved by hand and what was rejected, with the run links. Month-end reconciliation is a filter on that table.
Limits — what this does not do
- IntelliDocs handles up to 20 pages per file and Latin-script documents; a 40-page statement needs splitting first.
- Accuracy is measured on your invoices during the sandbox, not promised in advance; a review step stays in the flow for field that fails validations.
- Desktop accounting systems (QuickBooks Desktop, CONTPAQi, Domínio) need the bot variant of this use case.
Questions about this process
Yes. XML attachments are parsed directly, the PDF representation is kept for the approver, and the fiscal fields (UUID, chave de acesso, CUFE) are carried into the bill.
It becomes an approval card with the image and the fields side by side. Nothing posts until a person answers; after 24 hours the card is escalated.
When the accounting system exposes POs through its API (NetSuite, Xero, QuickBooks Online), yes — two-way match on vendor, amount and PO number.
Build this on your systems in a guided sandbox.
Tell us the process; after a 30-minute call the sandbox is ready from 24 hours, and we build the first run with your team.