Identify who can commit each company.
A group purchasing login should identify exactly which organisation the person may order for. The login, legal buyer and delivery location need separate checks. A shared email domain or a familiar group name is weak evidence of authority to commit another entity.
This matters when a Singapore procurement team buys for several regional businesses. Central buyers may negotiate common terms while orders, invoices and delivery responsibilities belong to different companies. A portal that looks convenient can obscure those boundaries unless the entity choice is both visible to the buyer and enforced by the receiving process.
Before approving a NetSuite-connected B2B portal, ask for a demonstration of permitted orders and deliberately denied ones. The most revealing test is often a buyer who used to be authorised.
The person logging in is the actor. Their identity establishes who requested an action and which approved access relationship applies.
The contracting buyer is the organisation accepting the purchase obligation. It needs its own controlled record and a clear association with the resulting order. A group relationship does not automatically grant every employee access to every company's account.
The delivery location tells the warehouse where the goods should go. It may belong to the buyer, another group company or an approved third party. It does not, by itself, establish who can place the order or receive its invoice.
On the seller's side, identify the entity taking the order too. This becomes important where a Singapore supplier and another regional seller serve related customers through one experience. Treat buyer and seller entity references as explicit design decisions, not labels inferred from the delivery address.
The following case is invented to show the testing method. A Singapore-based procurement coordinator, Mei, buys for two companies in the same group. Company S has a Singapore delivery site. Company M has a Malaysian delivery site. Mei's employer is Company S, but Company M has separately authorised her to place specified orders for it.
The proposed portal gives Mei an entity selector. Choosing Company M should change the visible commercial context to Company M's approved account. An order sent to Company M's warehouse must remain associated with Company M as buyer, even though Mei signs in from Singapore.
Another employee, Aaron, works for Company S and has no authority for Company M. He receives a forwarded link to Mei's draft order. Opening that link must not expose Company M's confidential pricing or allow him to submit the draft. An empty navigation menu alone would not prove this result; the test must attempt the underlying action through the available supported route.
Now Mei transfers to another employer. Her old authority must be reviewed and removed where it no longer applies. An existing browser session, saved draft or reordered historical purchase should not quietly preserve powers she has lost. The implementation team must demonstrate the actual session and access-revocation behaviour rather than promising an unspecified immediate effect.
SuiteCommerce MyAccount provides account self-service, including transaction visibility and supported invoice-payment, reorder and quote-related functions. It is distinct from the full catalogue shopping experience in SuiteCommerce. Standalone MyAccount also has its own licensing. Confirm the actual route and entitlement before using “customer portal” as shorthand for a complete B2B storefront.
If the requirement is to browse a catalogue and assemble new orders, demonstrate that journey in the proposed commerce platform. If the requirement is mainly to retrieve account information or reorder prior purchases, test that narrower journey. A custom portal introduces a separate application and integration boundary, with its own authentication, authorisation and support work.
NetSuite roles govern access to record types, tasks and pages. That does not prove every customer-entity relationship will behave correctly through a particular portal or connector. The solution team needs to show how a signed-in person becomes an authorised request for the specific buyer and action.
Ask for the configuration record, supported extension or custom component responsible for each rule. This makes future changes reviewable and prevents a sales demonstration from becoming an undocumented security specification.
Use this filled illustrative matrix as a test specification. In each case, preserve the actor, requested action, target entity, expected result and evidence reference.
Use ordinary buyer accounts throughout. An administrator's successful transaction says little about the restrictions that customer users will experience.
A new delivery location, added group company or changed buyer role can alter the access boundary. Build those events into the operating procedure. Decide who can request the change, who can validate it and what evidence must remain available afterwards.
For Mei's group, adding a new warehouse should not silently extend Aaron's company access. Reassigning Mei's employment record should trigger a review of her separate buying authority rather than an assumption that the relationship follows her forever. The exact automation, if any, is something to configure and test.
Also examine exports, emailed documents and support impersonation tools where they form part of the solution. A portal screen can correctly hide another company's order while a downloadable file or support route exposes it. Test only authorised scenarios in a controlled environment and retain enough evidence to explain the result without spreading unnecessary customer data.
The final review screen should make the buyer entity, delivery destination and intended commercial context easy to recognise. The backend must still validate them. Clear labels help people catch mistakes; they do not replace enforcement.
In the illustrative case, Mei should be able to say, “I am ordering for Company M, to its approved warehouse,” before submission. Operations should be able to trace that choice into the resulting NetSuite order. If either side must infer the buyer from an address or free-text note, the design needs more work.
Take the filled authority matrix to a customer portal review. A useful review will establish which proposed actions are supported, which require additional design and which should remain unavailable until authority can be proved.