Vendor Self-Service Portal

The problem

Accounts payable inboxes are where supplier relationships go to be processed badly. A vendor emails an invoice as a PDF attachment; someone downloads it, keys it into NetSuite, maybe matches it to a purchase order, maybe not. Three weeks later the vendor emails again asking whether it was received. Someone searches the inbox, finds the original, checks NetSuite, and replies. Meanwhile a buyer is chasing the same vendor by phone to find out whether a purchase order was accepted and when it will ship, because nothing in the system records an acknowledgement.

The cost is not just AP headcount. It is invoices sitting unbooked at month-end because nobody keyed them, duplicate payments when the same PDF arrives twice under different subject lines, disputes that surface at payment time instead of at receipt time, and buyers with no reliable promised-date to plan against.

NetSuite has a vendor record, purchase orders, bills and a payment run. What it does not give you out of the box is a place for the supplier to do any of this themselves.

What ECOSIRE builds

ECOSIRE builds a vendor-facing portal on your own NetSuite account, delivered as an SDF project. Suppliers log in, see only their own data, and transact directly against your NetSuite records — no middleware, no separate database that has to be kept in sync.

Access model

The portal runs on SuiteScript 2.1 Suitelets served through NetSuite's own authentication. Vendor users are provisioned as contacts against the Vendor record with a restricted role, and every Suitelet enforces the vendor scope server-side on every request rather than trusting anything passed from the browser. A supplier cannot see another supplier's purchase orders by changing a URL parameter, because the record's vendor field is checked against the logged-in user's vendor on every load. Where you need a login-free path for occasional suppliers, we can scope a token-authenticated variant instead.

Purchase order acknowledgement

The vendor sees their open Purchase Orders with line detail: item, quantity, requested date, unit price. They can acknowledge the whole order, acknowledge with a different promised date, propose a partial quantity, or reject a line with a reason. A User Event script writes the response back onto the Purchase Order and its lines using custom fields for acknowledged status, promised date and vendor reference, so your buyers see the acknowledgement inside the standard PO record and your saved searches can report on unacknowledged orders older than N days.

Invoice submission

The vendor submits an invoice against one or more purchase orders. The portal pre-fills from the PO lines and the received quantities, so what the supplier submits is already structurally matched rather than free-text. Attachments — the supplier's own PDF, delivery notes, certificates — are stored in the NetSuite File Cabinet and linked to the resulting record.

Submissions land as a staging custom record, not directly as a Vendor Bill. This matters: it means an invalid or disputed submission never becomes a posted transaction. A Map/Reduce or Scheduled script runs three-way matching between the submitted invoice, the Purchase Order and the Item Receipt, applies your tolerance rules on price and quantity, and either creates the Vendor Bill or flags the submission for AP review with the specific mismatch named. Duplicate detection runs on vendor plus invoice number plus amount before anything is created.

Approval routing

SuiteFlow workflows route exceptions to the right approver based on your rules — amount thresholds, department, subsidiary, or the specific mismatch type. The vendor sees a status on their submission that reflects where it actually is, so the "did you get my invoice" email stops being necessary.

Payment status

Suppliers see their own bill and payment history: which bills are open, their due dates, which have been paid, the payment date and reference. This is read directly from the Vendor Bill and Vendor Payment records through a scoped saved search, so it is never stale. Remittance detail can be exposed at the level you choose during scoping.

Vendor self-maintenance

Suppliers can submit changes to their own contact details, remittance information and compliance documents. These land as pending change requests on a custom record for your team to approve rather than writing straight to the Vendor record, because letting a supplier silently change their own bank details is how payment fraud works.

Notifications and integration surface

Scheduled scripts drive email notifications — new PO awaiting acknowledgement, invoice status changed, payment issued. SuiteTalk REST endpoints are exposed where you have larger suppliers who would rather integrate their own system than log in to a portal, so the same validation and matching path serves both.

Who this is for

This fits organisations with enough recurring suppliers that AP inbox handling is a real cost — typically manufacturers, distributors, construction and multi-site services businesses — and where purchase orders are actually used rather than being a formality. It is most valuable when you already run three-way matching and want the supplier to feed it cleanly, and when procurement needs reliable promised dates.

It is less useful if most of your spend is on credit cards and ad-hoc purchases without POs, since there is nothing for the supplier to acknowledge or match against.

How delivery works

1. Scoping call. We map your current AP flow: how invoices arrive, what your matching tolerances are, who approves what and at which thresholds, whether you are on OneWorld and how subsidiaries affect vendor visibility, and which suppliers would use a portal versus integrate directly. We look at your existing PO and Vendor Bill customisations so the portal fits what is already there.

2. Fixed quote. You get a written scope covering the exact portal screens, the matching and tolerance rules, the approval routing, the notification set, and what vendors can and cannot self-maintain. The price is fixed against that scope.

3. Build. ECOSIRE writes the SDF project — Suitelets, client scripts, custom records, custom fields on Vendor and Purchase Order, Map/Reduce matching, SuiteFlow approval workflows, saved searches, roles and permissions. Typical lead time is one working week.

4. Install in sandbox. Everything deploys to your sandbox first. We provision test vendor logins, run real purchase orders through acknowledgement, submit matching and deliberately mismatching invoices, and prove the approval routing and the access scoping. Access scoping is tested adversarially — we attempt cross-vendor access and show you it fails. You sign off in sandbox.

5. Production deployment. The same SDF project deploys to production. We onboard an initial vendor group with you rather than switching every supplier on at once, so AP can absorb the change and any rule adjustment happens with a small blast radius.

6. Support window. Two weeks covering defects, tolerance and routing adjustments found in real use, and help onboarding the remaining vendor population. The project is an unmanaged bundle in your account and you own the source.

This is built to order. There is no download and no trial instance — the portal is written against your approval rules and your matching tolerances, because a portal that enforces someone else's rules is worse than no portal.