Integrations

NetSuite Integration

Vendor bills, purchase orders and receipts between NetSuite and PTAS AI, matched and posted with status written back.

Man in glasses checking a printed document against his laptop at a shared office desk

What moves

What flows between NetSuite and PTAS AI

Documents and master data come in. Vendor bills, attachments and status go out. NetSuite stays the system of record, and the purchase order stays the spine of every bill.

NetSuite or NetSuite OneWorld

Vendors, purchase orders, item receipts, vendor bills, vendor payments

The documents

Supplier invoices, credit memos, packing slips, statements

Your configuration

Subsidiaries, departments, classes, locations, tax codes, approval routing

PTAS AI

Vendor bills created from the documents

One bill per document, lines taken from the purchase order where there is one, segments set, the invoice file attached, created only after approval.

Approval and payment status back in the queue

Approval status and the vendor payment applied to each bill are read back, so FinSuite knows what is held and what was paid.

A trail on both sides

The NetSuite internal ID sits on the FinSuite record; the invoice file sits on the bill, in the File Cabinet.

NetSuite is a planning example here, not a packaged connector. Your edition, features and customisation, the route your administrator will approve, and who approves what are confirmed in discovery.

How FinSuite posts to a ledger

Integration methods

How NetSuite can be connected

Four ways in. NetSuite web services cover most accounts; the customisation in yours decides how much more is needed.

Native

What NetSuite does itself

NetSuite offers its own bill capture and AP automation options, and some customers run them. We publish no SuiteApp, we do not claim Built for NetSuite status, and nothing on this page is a packaged connector.

API

SuiteTalk REST and SOAP web services

NetSuite web services read and write vendors, purchase orders, item receipts and vendor bills, and SuiteQL answers queries. Authentication is token-based or OAuth 2.0, through an integration record and a role your administrator creates. The route we would expect to propose for most accounts, confirmed in discovery.

File

CSV import

The CSV Import Assistant loads vendor bills from a file, through a saved import map your team runs or a script runs on a schedule, with the results file checked for rejected rows. Slower than web services, and sometimes the route an administrator is most comfortable approving.

Custom

RESTlets, or many subsidiaries

Where your account relies on SuiteScript, SuiteFlow approvals or custom segments, a RESTlet written with your administrator can respect them. OneWorld accounts with many subsidiaries, or NetSuite as one of three systems in the flow, need orchestration on top.

The route for your account is confirmed in discovery, against its edition, features and customisation. For most accounts we would expect SuiteTalk REST, with vendor bills created from the purchase order where there is one, so NetSuite keeps the link between order, receipt and bill and your buyers see any variance where they already look. Web services calls count against your account's concurrency limit, which depends on your service tier and licences, so the integration is sized to fit beside everything else that already calls NetSuite. A heavily scripted account may push the work towards a RESTlet; we would rather say so in discovery than find out from a failed save.

What we would not automate. A vendor bill is not created until the vendor exists in that subsidiary, the match passed your tolerances and someone with the right limit approved it. We would not bill a line before its item receipt exists, and we would not ask for the Administrator role, or a role that can approve bills or create payments. The integration role reads what it needs and creates vendor bills.

Illustrative example · a bill for what arrived

What happenedNetSuite recordDetail
Invoice read: three lines, every field scoredDocPro recordGST on each line
Vendor matched on tax registrationVendor, subsidiary INBank agrees
Order found: three lines open, rates agreePO1187Currency INR
Receipt checked: lines 1 and 2 receivedItem receipt IR0442Line 3 not yet
Bill created from the order for lines 1 and 2Vendor billPending approval
Line 3 held until its receipt existsHeld in FinSuiteBuyer told why
1 line held Two lines billed against what the warehouse received. The third is not billed early, and the buyer sees the reason.

Illustrative data. A bill created from the purchase order keeps the link between order, receipt and bill inside NetSuite, so what is still to be billed stays visible there too.

Field mapping

Where each finance object lands in NetSuite

The mapping is agreed before build and kept per subsidiary, in the records and segments your administrator already uses. This is the starting point we bring to the assessment.

Finance objectIn NetSuite
Vendor The vendor record, with its subsidiary on OneWorld, terms, currency, tax registration and bank details. We match on tax registration and bank account before proposing a new vendor; a name alone is never enough. Your team creates it, through your own vendor approval.
Purchase order The purchase order and its lines, matched line by line on item, quantity, rate and currency. Where there is a PO, the bill is created from it, so each line carries the order reference and NetSuite can show what is still to be billed.
Goods receipt The item receipt against the order. We read the quantity received per line, so a partial receipt produces a partial bill and the rest waits. Where goods are not received in NetSuite, a packing slip read by DocPro gives FinSuite the third leg of the match.
Invoice A vendor bill with item or expense lines, department, class and location on each line, plus custom segments where you use them, and the invoice file attached from the File Cabinet. Approval status follows wherever approval runs.
Tax The tax code on each line, under SuiteTax or legacy tax as your account runs it, so NetSuite calculates what it expects. In India we check GSTIN, HSN or SAC and place of supply against the document. A difference beyond your tolerance is held in FinSuite before the bill exists.
Payment status The vendor payment applied to the bill, and the bill status, read back on a schedule through web services or a saved search.

The entry, on both sides · Illustrative example

FinSuiteValidated
VendorV-2041
Ledger5210
DimensionPlant 2
Net / tax₹ 2,29,000 / 41,220
Your ERPSystem of record
Creditor2041
GL account5210
Cost centrePLANT2
Document4500091827Posted
Linked both ways The ERP document carries a link back to the invoice image it came from.

Field mapping is yours to define. Entries are validated against it before they reach the ERP, not rejected by it afterwards.

Security of the connection

What protects the link to your NetSuite account

Four controls, each one visible to your NetSuite administrator. None of them depends on trusting us.

An integration record and a role you own

Your administrator creates the integration record and a dedicated role, and issues the tokens or certificate. Credentials are stored encrypted and can be revoked in NetSuite at any time, without touching anyone's login.

Least privilege, per subsidiary

No Administrator role, no bill approval, no payment rights. The role reads vendors, orders and receipts and creates vendor bills, restricted to the subsidiaries in scope, and is reviewed when the workflow changes.

Every write logged with its evidence

Each bill we create records the document it came from, who approved it and the internal ID NetSuite returned. A rejected write goes to a person with the error NetSuite gave.

Sandbox first

The mapping is built and tested in a sandbox account with a copy of your configuration, and moves to production after your AP team has seen the bills. If you do not license a sandbox, say so at assessment and the test plan is agreed with your administrator.

FAQ

Questions NetSuite administrators ask

Do you work with NetSuite OneWorld and several subsidiaries?

Yes. One integration, one mapping per subsidiary. Each subsidiary has its own vendors, tax codes and approval routing, and the role is restricted to the subsidiaries in scope. The review queue is shared, with the subsidiary as a dimension, so one team can work all of them.

Will bills appear in NetSuite before they are approved?

Only if approval runs in NetSuite. If you use vendor bill approval routing, we create the bill pending approval and leave it to your routing. If approval runs in FinSuite, the bill is created once it is approved. One place approves, never both.

Our account is heavily customised. Does that change the route?

It can. Custom fields, custom segments, SuiteFlow approvals and scripts that run when a bill is saved all affect what a web services call has to send. We read the customisation in discovery, and where it runs deep, a RESTlet written with your administrator is the safer route.

NetSuite is owned by Oracle. Is this the same as your Oracle integration?

No. NetSuite is a separate product with its own records, interfaces and administration. Nothing on the Oracle page about Fusion Cloud ERP or E-Business Suite applies here.

Is this a SuiteApp or a NetSuite partnership?

No. We do not publish a SuiteApp, and we do not claim Built for NetSuite status or a partnership with Oracle NetSuite. The connection is built for your account, authorised by your administrator, and documented for your auditors.

Next step

Bring a month of vendor bills and your subsidiary list

An assessment starts with your real documents and a sandbox account where you have one. Nothing is written to production NetSuite until your AP team has seen the bills.