B2B Ordering Portal + Existing ERP: When Do You Need Custom Development?

TL;DR

• Evaluate the portal and ERP connector together. A storefront feature does not prove that the same rule survives the transfer into a sales order.
• Separate the person ordering, the customer account being billed and the delivery location. Each can affect access, prices and order handling.
• Make units explicit. Five cartons of twelve items must not become five individual items or sixty cartons in the ERP.
• Distinguish a submitted request from a confirmed order. Buyer approval, seller credit checks, allocation and shipment are separate decisions.
• Test a repeat order after conditions change, including pack size, contract price and available stock. Reordering should not silently reuse expired terms.

A repeat order still needs the right commercial context

For example, suppose a maintenance-supplies distributor receives repeat orders by email. Customers buy in cartons, each account has agreed prices, and some companies order for several delivery locations. Staff identify the customer, check the terms, enter a sales order in the ERP and reply with availability.

The business wants customers to do the routine ordering themselves. Its ERP, the system already used for inventory, sales orders and accounting, is staying. The proposed portal must remove the re-entry without changing what a carton means or promising stock that operations cannot supply.

This distributor and the examples below are hypothetical. They describe requirements to test, not a Caemcore project.

Start with an existing customer's normal reorder and one that needed correction. Identify what the employee checked between receiving the email and confirming the order. Those checks belong in the proposed workflow, whether they are automated or deliberately retained for review.

If customers only need documents and job updates, the narrower question in our client-portal guide may be more relevant. Here the task is buying goods under an existing commercial relationship.

What can ready-made B2B software already do?

Customer-specific buying experiences are not exclusive to custom portals. Shopify's B2B feature overview includes company accounts, catalogues, quantity rules, payment terms, purchase-order numbers and reorders. Those capabilities are a reason to evaluate an existing product before commissioning their equivalents.

Check the intended subscription. Shopify's current plan comparison makes B2B available across Basic, Grow, Advanced and Plus, but reserves direct catalogue assignment to specific companies or company locations for Plus. A demonstration of individual contract pricing is not a price quote for the cheapest plan.

There are also products built around ERP integration. Sana Commerce describes direct connections to SAP and Microsoft Dynamics, using ERP pricing, inventory and customer information. That makes an ERP-connected commerce product another route to investigate, not proof that every customized ERP installation works without additional implementation.

Use the following comparison to choose what to test. The examples above describe published capabilities, not a ranking or independent delivery assessment.

A custom interface does not require rebuilding accounting or inventory. Equally, a suitable ready-made interface may need a custom connection. Evaluate those scopes separately instead of letting the word custom stand for replacing the whole stack.

Test the connector, not just the storefront

A product may support a rule that its ERP connector does not transfer. Ask the supplier to show the same transaction on both sides, using the intended ERP version, installed extensions and account permissions.

For example, Microsoft documents a Shopify connector for Business Central that imports orders and can create sales documents. The existence of that supported route is worth checking before commissioning an equivalent integration.

Its price-synchronization documentation identifies a specific limit in the product-price export: the calculation uses a temporary quote with quantity one, so that export does not transfer quantity-dependent prices or discounts. The same documentation describes separate B2B catalogue configurations. A successful one-unit price sync therefore does not demonstrate your complete customer-and-quantity pricing policy.

Ask which configuration handles your case and who maintains any rules outside the ERP. The answer may be supported catalogue configuration, a different connector or a small extension. It is not automatically a new portal.

Require evidence for the operations you need, not just an account connection: retrieve the permitted catalogue, determine the applicable price, submit an order for the right account, obtain its actual acceptance state and retrieve subsequent changes. Mark an untested operation as a dependency in the proposal.

Write down what must survive the order handoff

For the distributor example, keep the ERP responsible for accepted sales orders, commercial account rules and fulfillment records. The portal owns the customer's session, basket and submission history. Any copies of prices or stock need a defined refresh and validation process.

That is a proposed allocation for this example. An existing commerce product might legitimately own some pricing. What matters is that the ownership is explicit and the ERP order preserves the terms the business accepted.

Do not identify a business account solely from an email domain. Ask an authorized administrator to establish the relationship between the user, company and permitted locations. A buyer ordering for one depot should not automatically see every location's invoices or negotiated prices.

The ERP's own distinctions matter too. Business Central's Shopify order documentation describes mapping sell-to and bill-to customers through company-location records. Demonstrate the intended mapping rather than treating the delivery address as sufficient evidence of who owes the invoice.

Five cartons must remain sixty items

Hypothetical example. A customer requests five cartons of a filter cartridge. Each carton contains twelve items. Its agreed price is $3 per item, or $36 per carton. Tax and freight are outside this illustration.

The expected order is 5 cartons × 12 items = 60 items, with a merchandise total of 60 × $3 = $180. The interface may display five cartons while the ERP stores sixty individual items. Both representations are acceptable only when the conversion, price basis and product reference remain explicit.

Now assume operations has confirmed that 48 items are available for this order. That is four complete cartons. Under the example's policy, the buyer can agree to four cartons now and one on backorder, or hold the whole request. The portal must not silently reduce the quantity, split a carton or invent a date for the remaining twelve items.

If a partial shipment is accepted, its merchandise amounts are $144 for the four cartons and $36 for the remaining carton. This does not prescribe when to invoice or add freight. Those rules need separate agreement, especially when splitting an order changes its delivery charge.

Quantity increments also need a precise meaning. Shopify's documented quantity rules apply at product-variant level: quantities of different variants cannot be combined to satisfy one variant's increment. If your customers buy mixed cartons, demonstrate that separate requirement rather than assuming a minimum-quantity setting covers it.

Finally, change the pack size in a test catalogue after creating a saved reorder. The new basket must identify the change and show the resulting goods and price. An old order for five cartons of twelve must not silently become five cartons of ten. Keep the historical order unchanged.

Decide what the customer can rely on before confirmation

Stock on screen, a requested delivery date and an accepted order are different information. Decide which source can commit stock and whether that commitment covers other sales channels as well as the portal.

A synchronized quantity needs a definition. Business Central's inventory connector documentation offers different stock-calculation methods, including projected available balance and free, unreserved inventory. It also supports filtering warehouse locations. A number labelled stock does not explain which of those quantities a buyer is seeing.

For the example, the final check must use the account, delivery location and required quantity. When availability cannot be verified, show an explicit pending request or pause confirmation under the agreed policy. Do not silently use an old stock copy as an unconditional promise.

Apply the same distinction to credit. Net payment terms say when payment is due; they do not by themselves establish that the seller has authorized another order on that account. Have finance define the credit-hold decision, its source and any permitted override. A custom portal cannot remove an unresolved credit rule by adding a pay-later option.

Separate the buyer's approval from the seller's review. The customer's purchasing manager may authorize a request while the distributor still needs to check stock or account status. Shopify supports submitting B2B checkout as a draft for seller review. That setting is not evidence that a separate purchasing hierarchy inside the buyer's company has been implemented.

Use clear states in the proposed workflow: awaiting buyer approval, received for seller review, confirmed, partially shipped and complete. Choose names the business understands and record what event permits each change. An ERP record being created may still leave a hold or release decision outstanding.

Ask for a reorder rehearsal with three disruptions

Run a non-production exercise with synthetic customers, test stock and notifications routed to the project team. Start with the five-carton order, the correct billing account and an authorized delivery location. Have an operator find its ERP record from the portal reference without copying it by hand.

Then introduce these disruptions. The purpose is to expose implementation gaps before choosing the development scope, not to request a production build as an unpaid sales demonstration.

1. The buyer changes location and uses an old basket

Switch from one permitted delivery location to another with different agreed terms. Open a saved basket created before a price or pack-size change. Check the catalogue, current quantities and total again before submission. A copied basket should save selection effort, not silently preserve conditions that no longer apply.

Try the same action with a user who lacks access to that location. Include a direct request for another company's order and document, not just a check that links are hidden. OWASP recommends authorization checks on every request, enforced outside client-side controls. These tests supplement, rather than replace, a security review.

2. The ERP accepts the order but the response is lost

Interrupt the response after the agreed ERP action has succeeded. Submit again using the supported recovery path. There must be one intended business order, with a traceable result, rather than a second order created because the browser showed a delay.

Microsoft's Retry pattern explains this failure: an operation may already have taken effect when its response fails to arrive. Ask the implementer to show how it retrieves or safely repeats the original request. A buyer's purchase-order number alone may not identify a unique submission if the business permits several releases against that number.

Give an operator the unresolved request. They should be able to establish whether it was accepted, held or rejected, and identify the next action. Keep customer-facing received separate from confirmed while the outcome is unknown.

3. A shipment is partial and the customer changes the remainder

Ship the four available cartons in the test, leave one open, then request cancellation of that remainder. Check the ERP quantities, portal history and customer message. Cancelling twelve unshipped items must not erase evidence of the forty-eight already dispatched or claim that a financial credit has been issued.

Do not assume order changes synchronize like initial creation. Microsoft's Business Central connector documentation says edits received from Shopify after an order has been processed are flagged rather than automatically propagated to the processed ERP document. That is a reason to define the amendment workflow, not an instruction to delete live sales documents to force agreement.

Record passed, failed and untested outcomes with the exact configuration. For each failure, distinguish a missing setting, an undecided business rule and a verified product or connector limitation. Only the last category provides direct evidence for new software, and even then a smaller extension may be enough.

What would justify a custom portal?

Custom development deserves a proposal when an essential buying task remains unsupported at acceptable cost and operational effort. A possible example is a customer ordering mixed packs against a contract that combines several ERP records, with approval and fulfillment rules the evaluated products cannot represent. Demonstrate that gap before designing around it.

A narrow integration may be the right purchase when the storefront already works and only a field mapping or order operation is missing. A custom portal becomes more plausible when the required customer journey and record model are themselves the constraint. Neither choice requires replacing an ERP that still performs its core work.

Conversely, a branding preference, customer-specific prices or a large catalogue is not sufficient evidence. If the ready-made route passes the required order and its exceptions, compare its full cost before adding another application to maintain. If the ERP cannot expose a necessary operation, a custom front end does not make that operation available by itself.

For broader synchronization design, our guide to connecting business systems without replacing everything covers ownership and recovery beyond the ordering channel.

Scope one buying cycle, not an entire new ERP

A useful first-release brief for the hypothetical distributor could cover approved customer accounts, agreed delivery locations, one representative product range, carton-based ordering, seller review, ERP order creation and partial-shipment visibility. Invoice collection, returns processing and replacing warehouse software remain outside that release unless the chosen journey requires them.

Ask the proposal to price the portal, connection, catalogue and customer mapping, testing and rollout separately. Include any required ERP partner work, subscription tier, hosting and ongoing support. Name who maintains pack sizes, price agreements, failed transfers and vendor updates. A storefront-design fee and an operating ordering-channel fee are different purchases.

Pilot with customers who actually reorder, on the devices they use. Ask them to identify the right account, repeat a purchase and understand an exception without coaching. Measure where they still need to email and which records staff still re-enter. Moving data entry to the buyer is not a useful result if staff must reconstruct every order afterward.

Keep phone and email available through a defined fallback that creates the same ERP records and checks for an existing portal request. For the first operating cycle, account for each submitted request as confirmed, awaiting action or rejected with a reason. Expand when buyers and staff can complete that cycle, not merely when the portal has a working login page.

About Caemcore

Caemcore builds custom software for companies that outgrew off-the-shelf tools.

Internal systems, integrations, web and mobile apps, and products built from scratch. Small senior team, Warsaw-based, working with clients across the EU, US and UK.

You get a price range and a timeline before development starts, a working demo every Thursday, and a final invoice that matches the number quoted on day one.

Not sure what you need? A 30-minute call, free: what the task actually is, whether it needs building or an off-the-shelf tool covers it, a range and a timeline. You get that whether we work together or not.

FAQ

Can sales representatives place orders on behalf of customers?

Yes, when the chosen system supports an explicitly authorized workflow. Record both the staff member performing the action and the customer account and location they are acting for. Apply the customer's approved terms rather than the representative's default catalogue. Keep manual overrides visible and permission-controlled. Do not ask representatives to share customer passwords to perform the task.

What happens when an employee leaves a customer company?

Provide a named customer administrator or seller-side process for removing that person's access. Preserve their historical order and approval records while ending active access as required. Check saved sessions, pending approvals and replacement approvers. A former employee's departure should not erase the company history or leave a purchase request waiting indefinitely for someone who can no longer approve it.

Can buyers see orders they originally placed by phone or email?

Include those orders when the ERP can expose them through the supported connection and the customer needs that history. Map them to the correct account and delivery location, distinguish their original sales channel and preserve their identifiers. An imported historical order must not trigger a new order or another customer notification. Test access using a buyer who is allowed to see only one location.

What if our ERP has no suitable API?

Check its supported import and export facilities, existing commerce modules and vendor-approved extension options. A scheduled exchange can support a request-and-confirm workflow when the business accepts the delay; it cannot establish an immediate stock or credit decision by itself. State what staff must review and how rejected records are recovered. Do not bypass the ERP's controls with direct database writes simply to make a demonstration work.

Should returns and invoice payment be in the first release?

Include them only when they are necessary for the chosen buying journey. Otherwise, retain the existing process and provide clear instructions from the portal. Showing an invoice, taking payment, requesting a return and authorizing a credit are different capabilities. Name their owners and test their accounting and order effects before presenting them as completed actions in the customer interface.

Sources

• Shopify, Overview of B2B features. Checked 15 September 2026.
• Shopify, B2B features by plan. Checked 15 September 2026.
• Sana Commerce, ERP-connected B2B commerce. Checked 15 September 2026.
• Microsoft Learn, Synchronize and fulfill sales orders. Checked 15 September 2026.
• Microsoft Learn, Synchronize prices with Shopify. Checked 15 September 2026.
• Shopify, Quantity rules and volume pricing in B2B. Checked 15 September 2026.
• Microsoft Learn, Synchronize inventory with Shopify. Checked 15 September 2026.
• Shopify, Managing checkout settings in B2B. Checked 15 September 2026.
• OWASP, Authorization Cheat Sheet. Checked 15 September 2026.
• Microsoft Azure Architecture Center, Retry pattern. Checked 15 September 2026.
• Caemcore, Systems review. Checked 15 September 2026.

Platform capabilities were checked on 15 September 2026 using first-party documentation and service pages, not hands-on comparison tests. Product and connector behavior still needs verification in the proposed subscription, ERP version and configuration. The distributor, quantities, prices and acceptance scenarios are hypothetical editorial examples, not Caemcore client results or commercial benchmarks.