Fortbras: three ERPs, many banners and one B2B portal for an auto parts network

Fortbras is a national consolidator of Brazil’s automotive aftermarket: a multi-brand network of well-known regional banners, such as Javali, Pegasus, Soma, T-Brasil, Total, Menil and União, that sells auto parts, motorcycle parts, tires, lubricants and accessories to repair shops, auto centers, parts stores, fleet operators and consumers. In August 2024, the trade press already counted 246 points of sale, 17 banners and more than 300,000 different parts in the portfolio (AutoData, Aug 30, 2024).

Growing by acquisition brings scale, and it also leaves a legacy: every banner arrives with its own ERP, its own price list, its own customer base and its own way of selling. In 2025, Fortbras decided to digitize the network’s B2B sales without asking any banner to replace its system. The portal went live on CWS Platform and, in the 16th month of the project, it is a real sales channel that keeps growing one store at a time.

Results so far

The figures below come from the project’s BI dashboard, for January 1 to October 13, 2026:

• More than BRL 30 million in digital revenue across more than 35,000 orders.
• Average order value close to BRL 900.
• More than 4,000 active customers buying through the portal.
• More than 30 branches from several banners with sales recorded in the channel.
• More than 400,000 sessions since April, when session tracking started, three out of four of them from logged-in customers.
• More than 600,000 offers published by the branches, covering more than 6 million units in stock.

What the proposal said and what the project became

The commercial proposal, from March 2025, described a B2B Commerce project for 28 stores, with about 100,000 SKUs, credit limits, own delivery and a launch in 3 months. The sales rep module was left out of the first phase.

The schedule held: the MVP started on July 1, 2025, at a branch in Fortaleza, and the first wave reached 18 stores in production in September of the same year. What changed was the size of the problem. The design that was born for 28 stores now supports:

	Proposal (Mar 2025)	Today
Stores	28	more than 30 branches selling, with a 260-store horizon
Catalog	about 100,000 SKUs	more than 300,000 products registered
ERPs	not detailed	3 active ERPs, 2 still to integrate
Sales reps	out of scope	Sales Hub in pilot, with an approval workflow
Registered customers	not detailed	more than 120,000

The platform kept up with that growth without a product swap or a re-implementation. New needs became configuration, and the few that required new code became improvements to the platform itself, which runs on the same version for every customer.

The design: one portal in front, many companies behind it

For the repair shop, Fortbras is a single portal: the customer logs in, sees the stores that serve them, sees the price that applies to them and places the order. Behind it, every order goes through seven layers, each one solving part of the group’s complexity.

1. One catalog. A global product registry shared by every banner, with the internal Fortbras code as the central identifier. The catalog carries no price: it describes the product, with vehicle fitment, cross references, equivalents and categories.
2. Inventory by store and by warehouse. Each branch publishes its own offer and balance, coming from its own ERP. A store can have several warehouses (parts, light-vehicle tires, heavy-vehicle tires) and still be a single store for the customer.
3. Governed visibility. Customers only see the stores and inventory the commercial rules allow. A customer who buys from two branches sees both; a customer served by one sees only that one.
4. Contextual pricing. The base price is never shown. The final price is calculated at the moment of purchase, based on ERP, banner, store, customer group, contract, product tag and state.
5. Credit-first checkout. Payment methods by store, credit limits by banner, minimum order values, invoiced payment terms and payment negotiated with the store.
6. Taxes calculated at the source. Before the order closes, the platform calls the tax service of the branch that will invoice it, and the customer sees the taxes in the catalog, at shipping and at checkout.
7. Orders back to the right ERP. The order is created in the portal and reaches the ERP of the branch that fulfills it, through a query API or a webhook, depending on each banner’s system.

Three ERPs in the same portal

ERP	Banners	Stores implemented (Jun 2026)
Transis	Javali, Pegasus, Soma, T-Brasil	18
Autcom (Citel)	T-Brasil, Menil, Pegasus	11
Protheus	Atacado União	1

The same banner can run on more than one ERP (T-Brasil and Pegasus run on two), which is why the rules cannot live in the ERP. They live in the platform, in the Commerce Rules Engine (CDL Workspace), while each ERP remains the source of inventory, base price, credit and invoicing for its branches.

Integrations

ERP communication is asynchronous by design: the ERPs send inventory, prices and rules to the platform, and the platform publishes orders for the ERPs to consume. No page of the portal depends on a branch’s ERP answering in that second. The deliberate exception is tax, which has to be calculated in real time by the branch that invoices.

• Batch inventory and pricing, with the internal Fortbras code, the warehouse and each product’s price rule tags (brand, discount limiter, campaign).
• Orders read through a query API (Transis) or delivered by webhook (Autcom), with status updates sent back.
• Tax service per branch, authenticated and called by the platform from a fixed outbound IP. It returns Brazil’s ST, IPI, ICMS, PIS and COFINS taxes.
• Price contracts via API, with priority and quantity-based discount tiers.
• Customers via API: registration, group membership, credit limits, welcome e-mail and password recovery.
• Self-registration by company tax ID (CNPJ): a customer without an account is sent to an external partner form, and the approved registration comes back to the platform via API.
• Analytics: portal events in Google Tag Manager and BI dashboards with revenue, orders, sessions, customers and offers by branch.

Pricing: four models in one portal

Each ERP brought a different pricing model, and none had to be abandoned:

• Transis (Javali, Pegasus, Soma, T-Brasil): base price, standard discount by banner, VIP tables, a discount limiter and priority promotions.
• Autcom at Pegasus and T-Brasil: a similar structure, with VIP by group and promotional contracts.
• Menil: closed tables, 1 through 7, with a final price by customer group and no percentage calculation.
• Protheus (Atacado União): contracts by state, no VIP and no promotions, with the final price taken straight from the contract.

On top of that sits a clear order of precedence: contracts beat percentage rules, which beat price tables. When two VIP groups compete for the same customer, the configured criterion applies. In June 2026 the portal had about 800 active contracts. Over the project, the platform added quantity-based price rules, tiered progressive discounts inside contracts (by headquarters or by branch) and sales multiples per product, all run by the platform and fed by the ERPs.

Different customers, different journeys

Fortbras’s customer base is not uniform, and the portal does not treat everyone the same:

• Store-based accounts. Each customer belongs to the groups of the stores that serve them. In June 2026 there were more than 3,000 customer groups.
• Customers of more than one branch. Intersection groups let a customer see two stores without mixing their rules. To keep invoicing clean, the cart accepts one store per order, with several warehouses from that store.
• VIP customers. In June 2026, more than 20,000 customers were in VIP groups, with their own prices by banner.
• Assisted selling. In the Sales Hub pilot, sales reps use the same interface as the customer, register customers straight into the right group and work with an approval workflow across rep, coordinator and manager.
• Visitors without a login. They can search the catalog but cannot see prices. On first access, customers confirm their registration data.

Configured, not coded

Most of what Fortbras needed was solved with the platform’s 1,029 configurable parameters, often on the same day it was requested: opening a new branch with another branch’s price rules, creating intersection groups, changing the default search behavior, turning a branch’s tax service on or off, restricting payment methods by store, giving branch managers access to the store panel, switching the product grid to the default listing view.

An operation this size also called for targeted product work, and it was done in the platform:

• A single store with several warehouses, for the wholesale operation that separates parts, light tires and heavy tires.
• A unique offer key per partner, for the ERP that sends the same product more than once.
• Taxes per branch, calculated at the source and shown in the catalog, at shipping and at checkout.
• Progressive quantity discounts inside contracts and sales multiples per product.
• Exact code search as the default, for the counter clerk who types the part number.
• Alphanumeric CNPJ support, ahead of the change by Brazil’s federal tax authority.
• Password recovery over WhatsApp and welcome e-mails triggered by the customer API.
• A new checkout, tested and approved by Fortbras in sandbox in October 2026.

A team that answers in minutes

The project has a direct channel between Fortbras’s project and technology team and the CWS Platform team, alongside the formal ticketing. In 16 months, it carried more than 5,000 messages. A few moments show the pace:

• In launch week, search started working for visitors without a login, without showing prices, after a one-day task force.
• On a Sunday, an import of 50,000 customers got stuck. The answer came in 12 minutes, and the load was redone in batches.
• A new branch, with the same price rules as another, was created in production and sandbox on the same day it was requested.
• When a wrong price in the source ERP reached the portal, the branch was switched off in 8 minutes, with inventory and settings preserved so it could come back online.
• The outbound IP change, required by Fortbras’s security team, was deployed overnight and monitored all day, with no impact on customers.
• Fixes to search, campaigns and taxes went out at night and on weekends, so stores could open the next day with the problem solved.

Not everything was simple, and an honest case should say so. Moving customer rules from postal code to customer groups, in September 2025, took days of fine-tuning with the branches. Search was rebuilt more than once until it behaved the way a counter clerk expects. Each time, both teams worked side by side, in the same room, until the issue was closed.

“Show Isra, acabei de testar vários cenários aqui e todos funcionando da forma que conversamos, muito obrigado!” (“Great, Isra, I just tested several scenarios and they all work the way we discussed, thank you so much!”) Fortbras project team, September 2026

A platform that changes with the operation

Today’s portal is not the portal of July 2025, and it did not have to be rebuilt to get here:

• Jul 2025: MVP in Fortaleza.
• Sep 2025: 18 stores in production; customers are defined by group, not by address.
• Oct 2025: the Autcom branches go live and the sales rep module pilot starts.
• Nov 2025: Protheus goes live, with the wholesale operation and its three warehouses.
• Feb 2026: warehouse restrictions and intersection groups in production for every branch.
• May 2026: reps register customers straight into the right group; nearly 190,000 products loaded into a single store with no duplicates.
• Jul 2026: sales multiples.
• Aug 2026: taxes in the catalog.
• Sep 2026: progressive quantity discounts, CNPJ self-registration, exact code search as the default and 10 more stores announced.
• Oct 2026: new checkout approved.

What the numbers reveal

• The portal became a work tool. Three out of four sessions come from logged-in customers. People who come in, come in to buy.
• Usage is recurring. Logged-in visitors average more than 60 sessions each since April. The most engaged customers have more than 2,000 sessions, with average session times of up to 18 minutes.
• Growth is steady. Monthly sessions more than tripled from April to September 2026.
• Sales are distributed. No single branch dominates the channel: the largest accounts for just over a tenth of digital revenue in the period, and more than 30 branches from several banners sell through the portal.
• There is plenty of room to grow. There are just over 4,000 active customers in a base of more than 120,000 registrations, and about 30 active stores out of a 260-store horizon. Every new store brings its customer base to a portal that is already in place.

Next steps

Fortbras is sticking with the approach that worked: one store at a time, no big bang. The next 10 stores are being implemented, two more ERPs are still to come, Sales Hub is getting ready to move beyond the pilot and the catalog is going through an enrichment round with AI agents.

The takeaway: a network that grew by acquisition does not have to choose between unifying its ERPs and selling digitally. With the rules in the platform, each banner keeps its own system, and the customer finds a single Fortbras.