Set up B2B pricing, VAT and payment terms in PrestaShop

What we would do

For a mixed retail and trade shop, we would start with the existing catalogue and native group pricing. Keep public retail buying available, put trade applicants through a separate approval decision, and grant invoice payment only after a credit decision. Choose the route against your actual modules, checkout, theme, customer data, markets, accounting or ERP integrations and the staff who will review applications and reconcile payments.

Make the change on a private staging copy with the live shop's configuration and integrations represented. Isolate customer emails, live payments and fulfilment exports. Rehearse the journeys below, obtain your accountant's agreement on the tax outcomes and sample invoices, then schedule the live switch with the old settings and account mappings ready to restore. Keep accepted orders and their records intact if you reverse the configuration.

If you want the gaps assessed first, the PrestaShop B2B & Wholesale Readiness Audit provides an ordered plan for the existing shop; implementation is separate and your accountant decides the tax treatment.

Understand native B2B mode

Under Shop Parameters > Customer Settings, enable B2B mode with PS_B2B_ENABLE. In the native registration form, this adds company and identification-number fields. Customer administration also exposes business data such as SIRET/APE, outstanding allowance, maximum payment days and risk information where supported.

The VAT number belongs to an address, not the Customer record. Address-format configuration and integrations determine where you collect it. The country's tax-identification-number requirement concerns the separate dni identification field; it is not a global VAT-field switch.

B2B mode does not itself approve trade applicants, perform a VIES lookup, make all trade sales exempt or enforce an available-credit ceiling. A stored risk label is information for your process, not an automatic credit decision.

The navigation in this guide targets modern PrestaShop 1.7, 8 and 9. Do not apply these menu paths unchanged to a 1.6 back office.

Separate customer groups from tax calculation

Create groups under Shop Parameters > Customer Settings > Groups. A group can define a price-display method, reduction and price visibility. Category access and payment restrictions provide additional controls.

The standard roles are Visitor for anonymous browsing, Guest for guest checkout customers and Customer for registered accounts. Read the configured group identifiers rather than hard-coding one installation's IDs.

A customer can have several memberships and one default group. Standard price display and group-scoped specific-price selection normally use the default group; merely adding Wholesale membership does not guarantee Wholesale pricing. Category and module access can consider multiple memberships.

Use groups for a manageable number of commercial tiers, such as Retail, Pending Trade, Trade and Wholesale. You can record VAT-related labels separately, but a single trade group can contain orders with different tax treatment.

Tax excluded changes the displayed price basis. It does not select a product's tax-rule group or remove the tax charged. Tax calculation uses the product's tax-rule group and the configured tax address, including relevant country and other address conditions.

For public consumer offers, retain the required tax-inclusive price information. A net/gross toggle needs clear labelling and correct totals. A separate multistore storefront can serve a dedicated business audience, but configure and test its groups, URLs and tax display explicitly.

When anonymous trade buyers need a net-price view, Tax Display Switcher provides a labelled net/gross choice without granting trade discounts or changing the tax charged. Check sale prices, crossed-out prices, delivery and totals in the same view, then test login and logout so a saved display choice cannot be mistaken for trade approval.

Configure discounts, contract prices and quantity breaks

A group-wide percentage reduction is a broad pricing rule. Product specific prices allow a set price or a reduction scoped to customer, group, quantity, country, currency and dates. Catalog price rules support range-wide conditions.

Specific-price priority chooses among eligible specific-price rows. It does not automatically cancel group or category reductions. In PrestaShop 1.7.8 and 9, an enabled group/category reduction applies after the specific-price calculation. For example, a €12 net specific price with a 20% group reduction becomes €9.60 before other effects.

Group-scoped specific prices normally match the customer's default group or an all-groups row. They do not all compete simply because the customer belongs to several groups.

For a €100 base price, you might intend this illustrative volume table. Configure the rules to produce these final figures, then test overlaps:

This read-only example inventories group-scoped specific prices. Use the actual database prefix and language ID:

SELECT sp.id_specific_price, sp.id_product, sp.id_group,
       gl.name AS group_name, sp.from_quantity,
       sp.price, sp.reduction, sp.reduction_type,
       sp.`from`, sp.`to`
FROM ps_specific_price sp
LEFT JOIN ps_group_lang gl
  ON gl.id_group = sp.id_group AND gl.id_lang = 1
WHERE sp.id_group <> 0
ORDER BY sp.id_product, sp.from_quantity;

specific_price has no priority column. Inspect specific_price_priority and PS_SPECIFIC_PRICE_PRIORITIES separately. The inventory query is not a resolved-price calculation.

Use customer-level specific prices for genuine account exceptions, while accounting for the maintenance cost of many contracts. Add product rules in the product's Pricing tab under Specific prices. Keep a documented map of tiers, default groups, category reductions and notable exceptions, including their source and who may change them.

Work through a price that is lower than agreed

If the agreed net contract price is €12 but your test cart shows €9.60, use the overlap example above to trace the difference. Check the account's default group, the matching specific-price row and the active group/category reduction before adding another override. Decide whether the contract price should receive that reduction, change the conflicting rule, and test both the affected account and an ordinary retail account.

For the volume table, test quantities 9 and 10, then each later boundary, in the product page, cart and final order. Keep the same currency, address and account while comparing. Also test a promotion during the contract period: a cart-rule discount is another layer to include in the agreed final price.

Control visibility, payment access and minimum orders

Set category group access under Catalog > Categories. A product assigned to another accessible category may remain accessible, so test direct links, search, listings and related products. Check guest and visitor access as well as approved accounts.

Use group price visibility for a login-for-pricing workflow when appropriate. Global catalog mode under Shop Parameters > Product Settings disables purchasing and has a separate Show prices option. It need not hide prices, and it affects the whole shop context.

Configure payment group, country and currency restrictions through the payment preferences screens and supporting payment modules. Revalidate customer eligibility at submission; a hidden payment option alone is insufficient protection.

Distinguish three minimums:

• A product or combination minimum quantity applies to that product's ordering rules.
• The global minimum order value is under Shop Parameters > Order Settings > General, backed by PS_PURCHASE_MINIMUM and expressed tax-exclusive.
• A group-specific or cart-wide quantity minimum needs an implementation that enforces that requirement.

A cart-rule quantity condition controls discount eligibility. It does not prevent checkout below a minimum quantity. Global product minimums can affect retail buyers too.

Verify applicants before granting trade benefits

Define who qualifies for trade pricing and who separately qualifies for credit. Collect only the details needed for that decision: company identity, registration details where applicable, business address, activity, contact information and proportionate references or documents.

Not every legitimate business has a VAT registration. A valid VAT number also does not prove that the applicant controls that identity. Check relevant business registers, contact details and supplied identity information; a residential address or free email address alone is not proof of fraud.

1. Keep applicants in a retail or pending state without trade benefits.
2. Review the business and record the decision and reason.
3. Under Customers > Customers, edit the account, set the intended memberships under Group access and explicitly select the pricing tier as its Default group.
4. Authorise credit separately with agreed terms and a limit.
5. Notify the applicant and provide a route for corrections or review.

Customer account creation does not guarantee an address exists yet, so an account-creation notification cannot assume that VAT data is on the Customer object. Use the application or address workflow for that information. Newsletter and opt-in flags are not trade approval or verified-email flags.

For the authenticated application workflow and its current policies, use the help page for B2B Account Approval, Trade Account.

Set a review target your team can meet. Revisit access when company details, activity or payment performance change. Revocation may require removing memberships and resetting the default group, while preserving lawful order records. Avoid silently auto-approving applications merely because a field is filled.

Keep applications moving without widening access

Give the application queue a named reviewer and a deputy, with a notification for a completed application and a visible status for the applicant. Separate requests for missing information from a rejection. When you reject, explain what can be corrected and leave retail access available if that is your policy. Use purchase history when reviewing commercial tiers rather than treating a promised order volume as evidence.

Restrict staff approval permissions and keep a record of who changed access. Rehearse rejection and revocation using an account with an open cart: its next submission must use its current eligibility rather than the permissions it had when the cart was built.

Determine VAT treatment for the actual supply

Check the seller's establishment, goods or services supplied, customer status and the movement or place of supply. A business group or a valid VAT number is only part of that decision.

Do not use Article 196 as the universal invoice basis for goods. Check the EU VAT Directive and national implementation with your tax adviser.

Great Britain is outside intra-EU goods treatment. Northern Ireland has special goods arrangements using XI identification under the Windsor Framework; see HMRC's XI guidance. Do not convert an ordinary GB buyer into an XI goods case.

Services have their own rules. Cross-border B2B reverse charge can still apply to UK services transactions; see HMRC's services guidance.

For consumer distance sales, OSS and destination-VAT rules are separate from this B2B workflow. Use the prices and VAT guide.

Work through a changed delivery destination

An approved French trade buyer gives your Belgian shop a valid French VAT number but asks for delivery within Belgium of goods dispatched from Belgium. Keep the commercial discount if the account still qualifies, but reassess the tax decision against that domestic delivery. The buyer's country and the stored number do not establish an intra-Community movement.

On staging, repeat the order with delivery to France, using clearly labelled sample validation and dispatch records to test how the evidence is linked to the order. For live qualifying supplies, keep the actual validation and transport evidence. Compare checkout tax, the order and the invoice in both cases. Ask your accountant to approve the expected outcomes before letting the integration choose them automatically.

Validate VAT details and handle service failures

VIES checks intra-EU VAT registration against national systems. Returned name and address information varies. It does not prove that the applicant owns the identity. If a result is missing or disputed, seek national tax-authority confirmation as described in the EU VIES guidance.

Normalise the country prefix without deleting valid letters from the number. Greece uses EL for VIES; Irish and Dutch formats can contain letters. Handle XI specifically for relevant goods transactions. Format validation filters malformed input; registration needs a separate check.

For a SOAP integration, the WSDL is https://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl. Bound both connection and response time. connection_timeout alone does not bound a slow response; see the PHP SoapClient options.

Distinguish invalid format, an authoritative invalid result, mismatched identity, and unavailable or delayed service. A SoapFault is not always an outage. Do not turn every fault into an invalid customer or an automatic exemption.

Choose and document an outage policy: ordinary tax pending review, a qualifying recent validation result, employee review or a controlled block as appropriate. Explain the outcome to the buyer and define rechecks and any later invoice correction with your accountant.

Keep dated validation records linked to the relevant customer, address and transaction. Preserve a consultation identifier when supplied, but do not assume every response contains one. Apply the relevant retention and data minimisation rules.

Rehearse the chosen fallback with the lookup unavailable. The buyer should receive the configured outcome and a clear explanation, while staff can find the affected order, the failure reason and the next action. A pending result needs an owner and a recheck process; a successful later lookup must not silently rewrite an issued invoice or remove the original evidence.

Keep tax-engine behaviour separate from segmentation

Core does not perform authoritative VIES validation. However, the PrestaShop 1.7.8 and 9 product-pricing paths contain a legacy shortcut: with VATNUMBER_MANAGEMENT enabled, a nonempty address VAT number and a country different from VATNUMBER_COUNTRY can disable product tax.

That shortcut is not proof of legal eligibility. Audit these settings and any tax manager or VAT module together so an entered number cannot bypass the intended policy.

Apply the tax decision to the configured address and supply. A domestic delivery, a changed billing identity or a mixed cart can require a different result. Never exempt all future orders just because the account passed one earlier check.

Optional group labelling is separate from exemption and default-group pricing. Automatic EU VAT Checker can add a configured membership while preserving the default group. Its address integration collects VAT beside business address details; ordinary registration only validates a VAT field if another integration supplies one. Its help page covers the current tax policy, validation history, pending checks and module-specific setup.

Design deferred payment and credit control

Core stores outstanding_allow_amount, max_payment_days and risk data. Customers > Outstanding and Customer::getOutstanding() provide native outstanding functionality. These are distinct from automatic checkout credit enforcement.

Core also records payments and associates them with invoices. A complete receivables workflow additionally needs an agreed term, a due-date rule, remaining balance, credit policy, collections process and correct handling of returns and credit notes.

Bank transfer or another offline method can create an order without capturing money, but the method's name and order status do not by themselves implement those additional controls. For a small approved-account workflow, manual reconciliation can be appropriate if it is explicit and maintained.

At submission, verify the customer, shop, term, currency, cart and remaining credit again. A strict ceiling needs atomic reservation or equivalent locking across concurrent orders, with safe handling of duplicate submissions and failed order creation.

For example, a €2,000 limit with €1,800 outstanding leaves €200 before pending reservations or other policy adjustments. Another €900 order exceeds that limit. Define whether the system refuses terms, offers immediate payment or uses an explicit approval process.

Do not calculate receivables by summing orders.total_paid_tax_incl where valid=1 or paid=0. Reconcile invoices and allocated payments, partial settlements, credit notes and cancelled obligations, with the correct shop and currency basis. Native outstanding calculations are a useful starting point, but audit their scope and currency assumptions too.

For current term policies, group-derived credit settings, submission controls and balance handling, use the help page for B2B Deferred Payment Terms.

Make collection part of the payment workflow

Assign someone to review upcoming and overdue balances, match incoming transfers and handle disputed invoices. Agree reminder wording, escalation and when new orders lose access to credit. If accounting software maintains the balance, define how settlements return to the shop and how staff spot an overdue or failed import. A checkout ceiling based on stale balances can reject a settled customer or allow further exposure.

Start new credit relationships with the exposure your business can carry, then review actual payment performance before widening it. Keep an immediate-payment route where permitted so a credit hold does not force staff to increase a limit merely to complete a sale.

Configure order states and payment documents deliberately

Under Shop Parameters > Order Settings > Statuses, inspect each state's payment, validation, invoice, shipment and email flags separately. Use a distinct on-terms status where staff must tell approved credit orders from bank transfers awaiting receipt, and test invoice availability and the intended fulfilment steps without recording an unpaid order as paid.

paid=0 does not by itself keep an order out of every revenue report or prevent a payment record. Test the complete order-state and payment-module path before allowing unpaid orders to ship.

Persist the agreed term, start event, due date and payment reference through a defined storage and rendering integration. Passing extra_vars to validateOrder() does not automatically save custom terms or insert them into PDFs.

Manage core invoice options and footer text under Orders > Invoices. A static footer can show general bank instructions, but it is not a per-order due-date engine. Include an accurate invoice number, payment reference, bank details and applicable terms, and verify the final document.

For qualifying intra-Community goods, show the appropriate exemption basis and VAT identifiers. Use reverse-charge wording for supplies where the recipient is liable, following national requirements. Apply wording from the actual tax decision rather than a trade-group label.

Deposit, proforma and split-payment workflows need their own payment, fulfilment and invoice rules. Prepayment reduces receivables exposure but does not remove every business risk.

Accept the invoice before allowing dispatch

1. Place a terms order as an eligible customer and confirm that the resulting state permits the intended fulfilment without claiming money has arrived.
2. Download the customer's invoice and read the due date, payment reference, bank details and applicable VAT wording. Compare them with the stored agreement and checkout result.
3. Record a partial settlement through the supported payment workflow. Confirm that the remainder stays due and that a reminder asks only for that balance.
4. Process a return and credit note, then compare the remaining obligation in the shop, customer statement and accounting system. Check that staff cannot mistake the credit note for an incoming payment.

Check payment periods, reporting and retention

Choose terms according to creditworthiness, cash capacity and applicable law. “Net 30”, “Net 60” and an early-payment offer such as “2% within 10 days, otherwise 30 days” require a clear start event and settlement process. Supporting multiple terms is not the same as installing multiple instances of one payment module.

As at 26 October 2026, Belgium's general B2B framework uses 30 days by default and a contractual ceiling of 60 days; check sector and scope rules. The Belgian parliamentary response on payment terms describes the current framework.

France's general agreed limits are 60 days from invoice or expressly agreed 45 days end-of-month, with special rules for some sectors and transactions. Use the French official payment-period guidance. Do not offer Net 90 simply because software accepts that number.

Prepare recapitulative VAT reporting and any applicable goods statistics from transaction-level records, not merely a customer-group export. Reporting frequency and thresholds depend on jurisdiction and transaction. Where goods statistics are required, check that your exports supply commodity codes, weights and values; order totals alone may not be enough.

In France, intra-EU goods reporting uses the état récapitulatif TVA; EMEBI is the separate statistical survey, while DES concerns relevant services. See French customs guidance.

Retain invoices, relevant VAT checks, dispatch records and corrections for the applicable period. Germany's general VAT invoice-retention period is eight years, subject to applicable extensions and exceptions; this is not a universal period for all accounting data. See the German Finance Ministry e-invoice FAQ.

A PDF alone does not satisfy a requirement for structured e-invoicing and submission. Poland's KSeF issuing phases began on 1 February 2026 for taxpayers above PLN 200 million in 2024 gross sales and on 1 April 2026 for others. A qualifying monthly invoiced-sales transition up to PLN 10,000 gross runs through the end of 2026, with exclusions and receiving obligations to check. See the official KSeF scope.

Terms tie up working capital. With steady €20,000 monthly invoiced sales and on-time payment, a simple 30-day model implies roughly €20,000 in receivables, and 60 days roughly €40,000, before tax, seasonality, deposits and other timing differences. Finance the actual cash gap from your cost and settlement schedule.

Test the complete B2B and retail journeys

1. Check anonymous, guest, retail, pending-trade and approved-trade views.
2. Test default-group changes, multiple memberships and price-rule overlaps at each quantity break.
3. Verify public prices, hidden categories, direct links, search results and payment restrictions. Test carrier availability and delivery charges for both retail and trade baskets.
4. Test domestic, qualifying intra-EU goods, services, export and relevant XI scenarios separately.
5. Try valid, invalid, malformed, unavailable and mismatched VAT checks, then change the checkout address.
6. Test credit below, at and above the limit, concurrent orders, duplicate submissions and failed creation.
7. Verify due-date calculation, invoice text, payment allocation, partial settlement, refund and credit-note handling for your integration.
8. Reconcile reporting totals and repeat the cases in each shop and currency you use.

Do not assume retail is unaffected by B2B configuration. Registration fields, global minimums, catalog mode, address settings and cache behaviour can affect both audiences. Share the final workflow, sample documents and reporting exports with your accountant and fulfilment team.

Run the access and price cases in separate browser sessions, then repeat after warming any full-page or fragment cache. If anonymous visitors receive another account's prices, identify the cache rule or integration serving that response. Retest login, logout and a tier change before making pricing public.

Plan the switch and hand over the controls

1. Record the current group mappings, price rules, tax settings, payment restrictions and order states. Identify scheduled imports that could overwrite the new setup.
2. Agree the deployment order with your developer. Create and test the policies before assigning existing accounts, then enable benefits only for the approved population.
3. Rehearse the switch on staging using representative existing accounts and open carts. Compare the expected prices, eligibility and outstanding balances with the accounting records.
4. Choose the live window and the person authorised to stop the change. Define which failure restores the previous settings and how staff will handle any orders accepted during the window.
5. After the switch, follow actual applications and orders through review, checkout, dispatch, invoicing and settlement. Keep the approved test cases for later theme, module or integration updates.

What to ask your developer or agency

• Which settings and modules decide approval, the default pricing group, tax treatment and credit eligibility, and can any import change them later?
• Which installed shop and module versions, checkout and theme were tested, and where are the account, cart and invoice examples?
• What prevents simultaneous terms orders from spending the same credit, and how are failed creations, cancellations and settlements reconciled?
• Where can staff find an unresolved VAT check, a failed balance synchronisation and a rejected application, and who acts on each?
• What exactly is restored if the switch fails, and how do accepted orders, invoices and payment allocations remain available?

Questions owners ask

Can the buyer add a purchase order number?

Make it an explicit requirement if their accounts team needs it to pay. Check where your checkout collects it, where it is stored and whether it reaches the invoice and accounting export. A free-text delivery message is a poor substitute for a purchase reference that must be searchable and carried through the workflow.

Can several employees use one company's trade agreement?

Decide whether they need separate logins, shared credit and a common billing identity. A matching company name on separate customer records does not establish a shared agreement. Ask the developer how approval, access removal and credit exposure are connected across those accounts before enabling terms for each employee.

Does reordering guarantee the old price?

Treat a reorder as a new purchase under current rules unless your agreement explicitly guarantees a price. Test an old order after a tier, price or product change, including unavailable items and current minimums. Show the buyer the recalculated basket before submission.

What if one bank transfer pays several invoices?

Allocate the received amount against the intended invoices through the supported accounting or payment workflow. Keep any unallocated amount visible and resolve differences with the buyer. Marking every related order paid would lose partial balances and make the next credit decision unreliable.