NetSuite AP automation means a vendor invoice goes from the AP inbox to a coded, matched and approved vendor bill in NetSuite without anyone retyping it, and a person only touches the invoices that are new, unusual or out of tolerance. The same flow works for QuickBooks Online and Sage Intacct; the record names and the API change, the controls do not.
Manual AP rarely costs only typing time. It costs the late fee on an invoice that sat in an inbox, the duplicate payment when a vendor resent a PDF, and the one email asking you to update a vendor's bank details. Below is the flow Benian builds around the ERP you already run, where people stay in the loop, and when a dedicated AP platform is the better buy.
Where AP time and money leak today
Invoices arrive in five places
A shared inbox, personal inboxes, vendor portals, paper mail and the occasional text photo. Nobody can say how many invoices are waiting or how old the oldest one is.
Approvals stall in email threads
The approver is traveling, the forward got buried, and the invoice misses its terms. Early payment discounts go unclaimed and late fees appear instead.
Matching to POs and receipts is skipped
When three-way match is manual, it gets done for large invoices and waved through for the rest, which is exactly where quantity and price drift hide.
Duplicates and changed bank details slip through
A resent invoice with a slightly different number, or a convincing email asking to update remittance details, gets processed because nothing compares it to history.
What NetSuite AP automation should change in a finance team's week
Measure the change, not the software. Before any build, count four things for a normal month: invoices received, the share corrected after entry, median days from receipt to approved bill, and late fees or missed discount terms. That baseline decides whether automation is worth building at all.
A good result: the AP queue holds only exceptions, approvers act from a phone message, and the controller sees every invoice's status without asking. If you handle a few dozen invoices a month from repeat vendors, the ERP's built-in tools and a cleaner approval rule may be enough. Start there.
Capture: email inboxes, vendor portals and scanned invoices
Capture starts with one AP address every vendor is told to use, plus forwarding rules from personal inboxes that still receive invoices. The workflow saves each attachment with its original email and treats one email with three PDFs as three invoices. Scanned paper invoices go to the same address.
Vendor portals with an export can be pulled automatically. Portals with only a login usually stay manual, because a script that clicks through a portal breaks the day the portal changes. Every document gets an intake record with arrival time, sender and a file hash, which is the first duplicate check and the answer to the auditor's question: where did this bill come from?
Extraction and coding with confidence checks
A language model reads the invoice and returns structured fields: vendor, remit-to address, invoice number, dates, terms, currency, PO number, totals, tax and lines. It reads unfamiliar layouts well, but it is not trusted alone. Code checks every extraction before anything reaches the ERP: lines add up to the subtotal, tax plus subtotal equals the total, the vendor matches an existing record by tax ID or remit-to details rather than name, and the PO belongs to that vendor.
GL coding follows your rules first. If a vendor always codes to one account and department, that rule wins. For mixed-spend vendors, the model proposes a code from that vendor's history and a person confirms it until your controller decides the suggestions are reliable enough. A new vendor, low confidence or a failed check always routes to a person with the reason written out.
Two and three way matching against POs and receipts
Two-way match compares the invoice to the purchase order: same vendor, same items, price within tolerance. Three-way match adds the receipt, so you pay only for what arrived. In NetSuite that means the purchase order and its item receipts; in Sage Intacct, the purchasing transactions; in QuickBooks Online, purchase orders where your team uses them.
Finance sets the tolerances: a price variance, a quantity rule and an amount above which any variance needs review. Partial receipts, partial invoices and freight lines missing from the PO each get an explicit rule. Non-PO invoices, such as utilities, skip matching and follow their own approval path.
Approvals in Slack, Teams or email
Routing comes from an approval table finance owns, by department, amount, vendor or project. The approver gets the invoice image, the extracted lines, the match result and approve or reject buttons. A rejection asks for a reason and returns the invoice to AP. Reminders escalate on your schedule to a named delegate.
The decision is written back to the bill in the ERP with a name and time, so the audit trail sits where the auditor looks. Where your team already uses NetSuite or Sage Intacct approval features, the workflow feeds them instead of replacing them.
Posting vendor bills to NetSuite, QuickBooks or Sage Intacct
Posting uses each system's supported API, never screen automation. In NetSuite the workflow creates a vendor bill, or transforms the purchase order into a bill so the PO link is kept, through web services under a dedicated integration role limited to the records it needs. In QuickBooks Online it creates a Bill with the attachment. In Sage Intacct it creates an AP bill through its web services. Xero accounts payable automation follows the same pattern with Xero bills.
Bills post as pending unless your controller decides that matched, approved invoices under a set amount can post directly. Payment runs stay with your team. Every post is logged with the ERP record ID, and a failed post retries, then alerts a named person instead of failing silently.
Fraud controls: bank detail changes and duplicate invoices
The most expensive AP mistake is paying a real invoice to a fake account, usually after an email from a compromised vendor mailbox announcing new bank details. Any remit-to or bank detail that differs from the vendor record is a hard stop. The workflow never updates the vendor record. It opens a task to call the vendor on the phone number already on file, never the one in the email.
Duplicate checks normalize the invoice number, removing spaces, dashes and leading zeros, then compare vendor, number, amount and date against existing bills and the open queue. Near matches are held, not rejected, since a corrected invoice or credit memo can look like a duplicate. Text inside a PDF telling the system to change a payee or skip approval is flagged as data, never followed.
Build around your ERP or buy an AP platform
Dedicated AP platforms are a reasonable buy, and sometimes the better one. If you need vendor onboarding with tax form collection, a supplier portal or payment execution across many methods and countries, a platform covers more than a custom flow. They typically charge by invoice volume or subscription, so model cost at your expected volume.
Building around the ERP fits a narrower gap: invoices read, coded, matched and routed inside the system your team already uses. The build runs in accounts your business owns, such as your own n8n account, with ERP credentials your team creates and can revoke. Cost is driven by the number of capture sources, entities and currencies, the state of your PO and receipt data, and how many approval paths exist.
Do not start with automation if your vendor master is full of duplicates, POs are raised after invoices arrive, or nobody owns the approval rules. Fix those first.
- Buy a platform: supplier portal, onboarding and payment execution are the main need
- Build around the ERP: the gap is capture, coding, matching and approval routing
- Start smaller: low volume, repeat vendors, or approval rules nobody has written down
How a build runs
- Baseline the month. Count invoices, sources, corrections, approval delays and late fees, and pull a sample of real invoices.
- Write the rules down. Finance owns coding rules, match tolerances, the approval table and direct-posting limits. The build follows them exactly.
- Run in shadow mode. The workflow processes real invoices while your team still keys them, and results are compared field by field.
- Go live with exceptions routed. Bills post as pending, approvals move to Slack, Teams or email, and exceptions land in one queue with a reason.
- Review and hand over. After the first close, compare to the baseline, adjust rules, and hand over documentation, logins and alerts.