Finding Adobe Commerce B2B Expertise in Malaysia: Custom Pricing and Quoting

B2B commerce projects fail on pricing and quoting far more often than on anything else, and almost always for the same reason: the rules that governed the business were never written down. They lived in a sales director's head, a spreadsheet, and thirty years of "we always do this for that customer."

Adobe Commerce has a genuinely capable B2B feature set — company accounts, tiered and customer-group pricing, quick order, requisition lists, and negotiable quotes. The platform is rarely the constraint. The constraint is finding a partner who will do the unglamorous work of turning informal commercial practice into rules a system can execute, and who will tell you which of those rules should not survive the transition.

This article covers how to assess that capability, including what certification does and does not tell you.

What certification proves, and what it does not

Adobe runs individual certifications for the platform — developer, architect, and business-practitioner tracks — and maintains a partner programme with tiers based on a firm's overall relationship with Adobe. Both are reasonable filters. Neither is evidence that a team has delivered a complex B2B pricing engine.

Here is the practical distinction:

The useful move is to combine them. Ask which named individuals hold which certifications, and whether those individuals are assigned to your project — a firm-level credential attached to a team you will never meet is marketing. Then ask for two B2B references, one recent and one at least two years old, and ask the older client what has changed since launch.

The question that separates specialists most reliably is not about credentials at all. It is: "Walk me through how you would model a customer who has a contract price on 40 SKUs, a volume break above 500 units, and a promotional discount that must not stack with either." A team that has done this asks you three clarifying questions before answering. A team that has not says the platform supports it.

How to vet a B2B partner in Malaysia

Beyond the certification questions above, five criteria carry most of the weight:

Demonstrated B2B delivery, not B2C delivery with a login. These are different products. B2B has buyers who do not pay, approvers who do not shop, prices that differ per account, and orders that arrive as a spreadsheet of 200 lines. Ask which of those the team has actually built.

Willingness to interrogate your commercial rules. The most valuable thing a partner does in discovery is find the contradictions — the customer with two contract prices, the discount that stacks in one system and not another, the rule nobody can explain. A partner who accepts your pricing brief without argument has not read it.

ERP integration depth. In B2B the ERP usually owns contract pricing, credit terms, and the customer's financial identity, which makes the integration inseparable from the pricing engine. Assess it as one problem, not two.

Local commercial context. SST treatment on B2B invoicing, payment terms and credit practice, and how your customers actually want to order — which in this market is frequently still by email or WhatsApp, with the portal expected to accommodate that rather than replace it on day one.

Operating capacity after launch. B2B rules change: new contracts, renegotiated terms, new customer tiers. A partner who cannot support that cadence leaves you with a system that is accurate on launch day and drifting by the second quarter.

Custom pricing: why it is harder than it looks

Adobe Commerce provides several pricing mechanisms natively, and most B2B requirements are a combination of them rather than a custom build:

• Customer group pricing — the coarse segmentation: distributor, reseller, retail.
• Tier pricing — quantity breaks on a product, optionally per customer group.
• Catalogue price rules — conditional adjustments applied before the cart.
• Cart price rules — promotions and conditional discounts at basket level.
• Shared catalogues — different products and different prices exposed to different companies.
• Contract pricing per company — negotiated rates for a specific account.

The hard part is not any one of these. It is precedence. When a customer qualifies for a contract price, a volume break, a group discount, and an active promotion simultaneously, exactly one outcome must be correct, and it must be the same outcome the ERP would calculate and the same one the sales team promised.

That precedence order is a commercial decision, not a technical one, and it is the single most common thing left undecided going into a B2B build. Get it written down and signed off before development starts. Then insist on a test suite that encodes it — a set of worked examples, each with a customer, a basket, and the correct final price, that runs on every deployment. Without that, every future pricing change is a gamble.

Two further traps worth naming. Price visibility is a real requirement in B2B: some customers must not see list price, some must see nothing before logging in, and some negotiate on the basis that their rate is confidential. That is an access-control design, not a display toggle. And rounding and tax base — per line versus per document, and where SST is applied — will produce totals a cent apart from the ERP if not fixed during architecture, which is enough for a document to be rejected in finance.

Quoting is a workflow problem, not a pricing one

Requests for quote look like a pricing feature and behave like an approval system. The mechanics that matter:

• Who can request. Which roles inside a company account may raise a quote at all.
• What happens next. Which sales representative receives it, what their authority is, and what they may adjust — line prices, quantities, shipping, payment terms, validity.
• Approval thresholds. Discounts beyond a limit requiring a second approver, with the limit itself configurable rather than hard-coded.
• Negotiation history. Both sides need to see what was offered and countered, and finance later needs to know why the price was what it was.
• Expiry and conversion. A quote is valid until a date, then becomes an order — and the order must carry the quoted prices, not recalculate them.
• Buyer-side approval. Many B2B customers have their own internal sign-off. A quote that converts to an order without accommodating that gets rejected inside the customer's organisation instead of yours.

Adobe Commerce supports negotiable quotes natively, and for a large share of businesses the native flow plus configuration is enough. Where custom work genuinely earns its cost is unusual approval topologies, integration with a CRM the sales team already lives in, and quote logic that has to reconcile with an ERP's own contract records. A partner who reaches immediately for custom development here has not tested the native path.

The rest of the B2B surface

Pricing and quoting get the attention; these determine whether the portal gets used:

Company accounts and roles. Multiple users under one account with distinct permissions — a purchaser who orders, a manager who approves, a finance contact who sees invoices but never a product page.

Purchase approval workflows. The customer's own internal rules, enforced in your system, because that is what lets them buy without leaving the portal.

Quick order and requisition lists. The most-used B2B features in practice, and the most underestimated. A returning buyer who knows their SKUs wants to paste a list, not browse a catalogue. Requisition lists turn a recurring order into one action. Both are native to Adobe Commerce.

Payment on account and credit limits. B2B customers pay on terms. That means credit limits, available credit checks at order placement, and a decision about what happens when an order would exceed the limit — blocked, held for approval, or allowed with a flag. The ERP usually owns the number, which makes this an integration question.

Order history and reordering at company level, not just per user, so a colleague's order is visible and repeatable.

B2B and B2C on shared infrastructure. Many Malaysian brands sell both ways. Adobe Commerce handles this through websites and store views over a shared catalogue, but the tax display, price visibility, and checkout rules differ per audience, and that has to be designed rather than discovered.

Bridzia's Adobe Commerce practice covers B2B commerce including company accounts, tiered pricing, quick-order and requisition lists, and custom module development for bespoke pricing and quoting logic where the native feature set does not reach.

How the implementation should run

The sequence that works:

1. Rules discovery before anything else. Extract the pricing and approval rules from the people who hold them, write them as worked examples, and get them signed off. Expect contradictions; resolving them is the deliverable.
2. Decide precedence, then encode it as tests. Every subsequent change is measured against this.
3. Prove the ERP integration on a thin slice — one contract-priced customer, one order, all the way through to the correct document.
4. Build the portal around the two features people actually use, quick order and reordering, before the ones that demo well.
5. Pilot with real accounts. Three or four cooperative customers using it for real orders will find more than any UAT script.
6. Plan the operating cadence for new contracts and rate changes before launch, not after the first one arrives.

Expect the timeline to reflect this. A standard B2C rebuild runs three to five months depending on integration complexity; B2B builds with custom quoting and pricing logic run longer, and the extra time sits in rules discovery and integration rather than in front-end work.

Common questions

Is Adobe Commerce good for B2B?

Yes — company accounts, shared catalogues, tiered and customer-group pricing, quick order, requisition lists, and negotiable quotes are native, and the platform handles B2B and B2C on shared infrastructure under different rules. It earns its complexity precisely where pricing logic and ERP integration are the hard part.

Do we need a certified Adobe Commerce partner for a B2B build?

Certification is a reasonable filter but not sufficient on its own. Ask which named certified individuals will be on your project, and pair that with references from delivered B2B engagements — company accounts, quoting, and contract pricing specifically, not B2C work with a customer login.

Can Adobe Commerce handle contract pricing per customer?

Yes, through a combination of customer groups, shared catalogues, tier pricing, and per-company contract prices, usually synchronised from the ERP that owns them. The design work is deciding which mechanism carries which rule, and what takes precedence when several apply at once.

How long does an Adobe Commerce B2B implementation take?

Longer than an equivalent B2C build. Most of the additional time is rules discovery and ERP integration rather than development. Any estimate produced before your pricing rules are written down is an estimate of the storefront only.

Should quoting be custom-built or native?

Start with native negotiable quotes and configuration. Custom work is justified by unusual approval topologies, CRM integration, or quote logic that must reconcile with ERP contract records — not by a preference for bespoke.

Where to start

Write down your pricing rules as worked examples — customer, basket, correct price — before you brief anyone. The exercise will find contradictions, and those contradictions are the actual scope of the project. A partner who engages with that document seriously is demonstrating the capability that matters more than any credential.

Bridzia has spent 14 years building Adobe Commerce (Magento) platforms from Kuala Lumpur for retail and FMCG brands across Asia, including B2B commerce and custom pricing and quoting logic. If you are scoping a B2B build and want the rules interrogated properly, tell us about the project.