Somewhere today, a purchasing manager at a company that runs on NetSuite entered a purchase order, saved it, generated a PDF, and emailed it to a supplier. At that supplier - a company that also runs NetSuite - someone opened the PDF and re-keyed every line into a sales order. Next week the supplier will email back an invoice PDF, and someone in accounts payable at the first company will re-key that into a vendor bill.
Two companies running on the same enterprise resource planning (ERP) platform, four documents describing a single transaction, and a person re-typing data at every step.
This happens thousands of times a day. There are more than 44,000 businesses running on NetSuite, and every one of them has a verified identity, an item catalog, live inventory positions, and a ledger that records what really happened. They are all, in a meaningful sense, already speaking the same language. And when they trade with each other, they do it by email.
I've been thinking about what it would take to close that gap, and here's what I've come up with.
The Idea
NetSuite customers opt in to a trade network. Joining means installing a SuiteApp that implements a set of standard services as RESTlets: what I sell, what I have in stock, what it costs you specifically, how to send me an order, and where your order stands. A central registry - the only centralized piece - records who's on the network and where each participant's endpoints live. From that point on, members trade account-to-account. Your purchase order arrives in my account as a sales order, pending my approval. My invoice arrives in your account as a vendor bill, already matched to the order that started it.
No re-keying, no PDF archaeology, and no middleware project, because both ends of every connection run identical code against the same platform.
If this sounds like what Electronic Data Interchange (EDI) promised decades ago, then you're reading it right. EDI delivered that promise mostly to large enterprises, because bridging wildly different systems takes integration budgets that mid-market companies don't have. A NetSuite-to-NetSuite network makes most of that difficulty disappear. Everyone runs the same ERP, so the cost of joining collapses to installing an app and working through a setup assistant.
The registry solves a problem that anyone who has connected two NetSuite accounts will recognize: RESTlet URLs are account-specific. So the app registers itself. On activation, it resolves its own deployment URLs and sends them to the registry, signed from inside the account. That handshake doubles as verification, since only code running inside a given account can register that account. Identity comes free with the architecture.
What the Standards Would Cover
The standards themselves should be versioned service contracts - deliberately small, and deliberately boring. A first version might cover:
- Catalog - the items a company has chosen to publish, with descriptions and identifiers.
- Pricing - partner-specific, because in B2B the price depends on who's asking.
- Availability - live quantities for published items, optionally by location.
- Order submission - send an order, receive an acknowledgment or a rejection.
- Order status - including shipment notices with tracking numbers.
- Invoices - retrievable by the buyer, so their account can draft matching vendor bills.
Two design rules matter more than any field-level detail. The wire format has to be a canonical document schema; every NetSuite account is customized differently, and if local custom fields leak across the wire, then the network drowns in everyone's snowflakes. The app's job is to translate between the standard and whatever the local account looks like. And order submission has to be staged: an inbound order lands as a proposal that a human reviews and approves, at least until a trading partner has earned auto-accept status. Nobody should write directly into someone else's ERP on day one.
I've seen this self-hosted standards model work before. PromoStandards did it for the promotional products industry - a neutral body defines the service contracts, each supplier hosts its own endpoints, and a directory tells you where everyone lives. It works even though every participant runs a different backend. Give every participant the same backend and the hardest part of the problem is gone before you start.
Discovery Changes What This Is
Document mirroring between existing trading partners is the obvious value, but it has a built-in limitation: it's only useful to companies whose partners are already on the network. Discovery removes that ceiling.
Make the registry searchable. A manufacturer needs a part - a bearing, a fastener, a widget of some particular spec. Today that search means directory sites full of marketing claims that someone last updated years ago. A registry built on live catalogs answers a different question entirely: who has 340 of these on a shelf right now, at what price, from a counterparty whose existence NetSuite itself vouches for. The listings maintain themselves, because they're a side effect of running the business.
When search fails, buyers post a request for quote (RFQ) and the registry routes it to capable sellers, who respond privately. Unanswered RFQs are valuable too - each one tells the network's operator exactly which supplier, in which category, to recruit next.
And then there's my favorite wrinkle: surplus. Nearly every product company sits on stock it will never sell through normal channels, and NetSuite already knows what that stock is - surplus is computable from quantity on hand and trailing consumption. The app could run that math and ask: you have 62 items with more than a year of supply on hand; want to list them? I believe that a surplus exchange is the perfect first market. The transactions are one-off and prepaid, the prices move fast, and the stakes are right for trading with a company you've never met.
Hasn't Oracle Already Started Down This Road?
Partly - and I think that the partial version makes the case for the full one. In early 2025, NetSuite announced SuiteProcurement, which connects NetSuite buyers to supplier catalogs through the Oracle Business Network. Buyers can punch out to the catalogs of large established suppliers, select items, and generate purchase orders without leaving NetSuite. The same announcement covered an integration with the Digital Business Network Alliance for exchanging electronic invoices with trading partners in the US.
Both of these are real progress, and both stop short of the idea I'm describing. SuiteProcurement casts the NetSuite customer in one role only: the buyer. The sellers on the other end are large suppliers who were already on Oracle's network - your company's own catalog never becomes discoverable, and your inventory never becomes sellable. The DBNA integration moves invoice documents between platforms, which is useful plumbing, and it has no directory, no discovery, and no concept of the installed base as a market.
So the on-ramp exists. Oracle has already decided that procurement and document exchange belong inside the suite. What's missing is the network where the 44,000 NetSuite customers themselves are the participants - on both sides of the transaction. As far as I can tell, nobody has proposed that, and I looked before writing this.
Why This Should Come From Oracle
So why should the full version come from Oracle rather than a third party?
Start with what first-party ownership makes trivial. Identity and verification are solved by construction; NetSuite already knows who controls every account. Distribution stops being a cold-start problem and becomes a rollout plan: a card on every admin dashboard, and a step in every new implementation. And the data-quality work that discovery depends on - normalizing messy item descriptions into something searchable - gets the best possible training data, because Oracle can work across the whole opted-in installed base in ways no third party ever could.
Then there's the competitive logic, which I find even stronger. Any ERP vendor can answer a NetSuite feature with a feature release. A network can only be answered with another network, and networks take years to grow. If your thirty most important trading partners transact with you through NetSuite, then leaving NetSuite means leaving the network - and I can't think of a stronger retention story.
SAP paid billions for Ariba and runs its Business Network as strategic infrastructure. NetSuite has no equivalent, in the market segment where B2B connectivity hurts most and integration budgets are smallest. That gap looks like an opportunity to me. A large one.
Opt-In and Who Pays
None of this survives contact with a CFO unless participation is opt-in and disclosure is default-deny. Nothing published, nothing discoverable, until an administrator turns it on and chooses what to share, and with whom: fully public listings, category-searchable with quantities hidden, visible only in RFQ responses, or surplus-only. Companies will participate in a network that shares nothing by default, and they'll refuse one that assumes consent.
On pricing, I'd keep the core free with the subscription - the directory and discovery search, plus document mirroring with existing partners - because that layer is the retention asset, and taxing it throttles the liquidity everything else depends on. Charge sellers for publication and placement; sellers get the leads, so sellers pay. Down the road, the durable business lives in payments and financing built on top of verified trade flow - an invoice that both parties' ledgers agree on is about the safest thing in the world to factor.
The Risks
Search quality is the make-or-break engineering problem. Mid-market item masters are a mess - the part you need exists in someone's account as WDGT-0032-BLK with a description of "wdgt 3in blk rev C" and no category. Raw catalog search over that returns garbage, and a buyer who gets garbage twice never comes back. The index needs an enrichment layer that normalizes descriptions and extracts real attributes, so search can match on meaning. Five years ago I'd have called that the project-killer. Today it's exactly what large language models are good at, which is the strongest "why now" in this whole idea.
Operations is the make-or-break organizational problem. A marketplace needs curation, dispute handling, fraud response, and someone working the RFQ recruiting queue - a muscle that ERP vendors don't naturally have. The failure mode I'd fear at Oracle's scale is a splashy launch followed by two release cycles of neglect. High visibility spends every first impression at once, so launch quality matters more under a big banner, and I'd rather see transacting gated to two or three high-density verticals at first than a thin film of inventory spread across everything.
And the garden stays walled. Your supplier on SAP or QuickBooks is invisible to this network, which is acceptable at mid-market density for years, and a real ceiling eventually. Gateways can come later.
What I can't find is a structural reason this fails. I've been looking.
Wrapping Up
Every piece of this already exists. Verified identities, published catalogs, live inventory, order-to-cash rails, and now embedded AI for the messy matching work - all of it is sitting in the platform today. What's missing is a decision: to connect 44,000 ledgers that already speak the same language.
If you work with NetSuite - as a customer, a partner, or a developer - then I'd genuinely like to hear what you think. Where does this break? What did I miss?
And if you're at Oracle NetSuite and any of this resonates, then here's something to consider: your customers are already trading with each other. Right now they're doing it by email.