From 30+ Price Lists to One Pricing Matrix
What we learned transforming multi-country pricing for a Latin American food manufacturer.
Here’s a question I’d like you to answer honestly.
If someone in your finance team asked you right now, “Show me exactly how the price of SKU #4,217 was set for our third-largest customer in our second-largest market last quarter,” how long would it take you to produce that answer?
If you work at a multi-country food company and the answer is anything other than “about fifteen seconds,” you have a pricing governance problem. You may not call it that. You may call it “how we’ve always done things.” But it’s a problem, and it’s probably costing you more than you think.
I lead a team of pricing technology professionals that helps food and distribution companies across the Americas solve exactly this problem. We design and deploy the platforms and processes that turn fragmented, manual pricing into something that actually scales. One engagement in particular taught us lessons I think every multi-country food company needs to hear. My team spent ten months transforming pricing for a Latin American protein manufacturer, and what we found along the way surprised even us.
The Starting Point: 30+ Spreadsheets and a Lot of Tribal Knowledge
The company produces and distributes protein products across four countries. When we started the engagement, their pricing “system” consisted of more than thirty separate Excel-based price lists, maintained by different people, in different countries, with different update cadences.
When we started mapping the actual pricing process (not the one in the policy manual, but the one that really happened) we found a few things that I suspect are more common than most organizations care to admit.
No one could explain the full price waterfall. Base price, regional adjustments, volume discounts, promotional discounts, customer-specific terms. Each layer was managed by a different team, in a different tool, with different approval logic. The final price a customer saw was the output of a process no single person could describe end to end.
Discount decisions varied wildly for identical situations. Same product, same customer profile, same volume, and we’d see 10-15% pricing variation across markets. Not because of intentional local strategy. Just because each country’s commercial team had developed its own habits and informal rules over the years.
And maybe most telling: many of the discount “processes” didn’t actually exist as processes. When we sat down to configure approval workflows for inventory release discounts, for example, we discovered there was nothing formal to automate. The commercial team would get a list of at-risk inventory, apply a blanket percentage, and push it out. No elasticity analysis. No margin floor. No approval trail. We had to help the organization design these processes before we could put them in software.
We see versions of this in nearly every engagement. Whether it’s a food manufacturer managing volatile commodity inputs across borders, or a building materials distributor managing tens of thousands of customer-specific price points across hundreds of locations, the underlying issue is the same. Pricing complexity has outgrown the tools and processes managing it. The business keeps getting more sophisticated, but the pricing infrastructure stays frozen in time.
The Insight That Changed the Project: Process Before Software
I wish I’d understood this more deeply before we started: the technology is the straightforward part. The organizational alignment is where the real work lives.
We had planned to follow a fairly standard agile methodology. Iterative sprints, rapid configuration, frequent client feedback loops. That works well with organizations that have implemented enterprise software before and understand the rhythm.
This client, despite being a sophisticated, well-run business, hadn’t been through this type of implementation before. The concept of defining requirements upfront, reviewing configurations in sprint demos, and formally signing off on completed user stories was all new. We underestimated how much education and hand-holding that would require. (I say “hand-holding” without any condescension. It’s genuinely hard to participate in a process you’ve never seen before, and we should have done more to prepare them.)
But the bigger underestimation was about process harmonization.
When you have four country teams that have each developed their own way of doing things over decades, getting them to agree on a single pricing workflow isn’t a technology problem. It’s a diplomacy problem. Every country team had legitimate reasons for their approach. The competitive landscape is different. The customer base is different. The regulatory environment is different.
What we learned, though, is that you can accommodate local flexibility within a standardized framework. The key is getting agreement on the framework first (the data model, the approval logic, the escalation paths, the KPIs) and then building country-specific parameters within that structure.
We invested heavily in “to-be state” workshops before we touched a single configuration. Each country team mapped their current process, then we facilitated sessions where they had to defend their exceptions. A lot of those exceptions turned out to be artifacts of habit rather than genuine business requirements. The ones that were real? Those became parameters in the system. Not separate processes.
The Hidden Dependency: Requirements Governance
If there’s one lesson from this engagement that my team now treats as a core principle, it’s this: the organization’s ability to make decisions quickly and with appropriate authority determines your implementation timeline more than any technical factor.
We lost meaningful time. Not because of technology constraints, but because pricing decisions that seemed simple on the surface turned out to have no established decision-making structure behind them.
I’ll give you a concrete example. We’d present a configuration for review, say, the discount approval matrix for a specific product family. The business team would look at it and realize they’d never actually formalized who has authority to approve what level of discount.
And that’s not a failing on anyone’s part. In an Excel-based world, these decisions happen informally. A phone call, a quick email, a manager’s verbal OK. Why would you codify something that lives in relationships and institutional memory?
But the moment you move to a system with defined workflows, every one of those informal agreements needs to become explicit. Who approves a 5% discount? What about 12%? Does it change by product category? By customer tier? By country?
These aren’t technical questions. They’re organizational design questions. And in a company that’s never had to answer them formally, each one requires discussion, alignment, and sign-off from the right people. That takes time. Often more time than the actual software configuration.
We learned (the hard way, honestly) to treat requirements governance as its own workstream. Not a byproduct of the software configuration, but a parallel effort that needs dedicated time, facilitation, and executive sponsorship. The companies that move fastest through pricing transformations aren’t necessarily the most technically sophisticated. They’re the ones with clear internal decision-making structures, or at least the willingness to build them.
What We Built: The Unified Pricing Matrix
The outcome was a single pricing matrix that replaced those thirty-plus spreadsheets. I want to be specific about what that means in practice, because “unified pricing matrix” can easily sound like consultant-speak for “we made a dashboard.”
It’s not.
One place to design a pricing scheme. Instead of each country building their own price list structure, there’s a shared architecture. Product groupings, customer segments, and discount tiers are standardized. A pricing analyst in any market can build, evaluate, and propose a new pricing scheme using the same logic and the same tool.
One approval workflow. Every price change (base price update, promotional discount, customer-specific exception) goes through a defined approval path. The system knows who needs to approve what, based on the type of change, the magnitude, and the market. There’s a complete audit trail. That question I opened with? Fifteen seconds now.
One set of guardrails. Minimum margins, maximum discount percentages, escalation triggers: these are configured as parameters, not tribal knowledge. Local teams still have flexibility, but within boundaries the organization has agreed upon.
And one source of truth for analytics. When leadership asks “what’s our average discount by channel across all markets?” that’s answerable. Which customer segments are contributing the most margin and which are eroding it? Visible. Commodity input costs shift and you need to understand the margin impact across every product line in real time? The data is there. I won’t pretend this is some revolutionary concept. But when you’ve been running on thirty separate spreadsheets, the visibility alone changes how the business operates.
What I’d Do Differently
If I were starting this over, a few things would change.
I’d invest more in change management upfront. Not training. Change management. Helping the organization understand why this matters, what will change in their daily work, and what won’t. We discovered that fear of losing local autonomy was the biggest source of resistance, and we could have addressed that much earlier with clearer communication about the standardization-with-flexibility model. By the time we figured that out, we’d already burned goodwill we didn’t need to burn.
I’d build the decision-making structure before the software. For each pricing area (base prices, volume discounts, promotional discounts, customer-specific exceptions, inventory release) I’d run a dedicated session to answer: Who owns this decision? Who needs to approve it? What are the boundaries? What triggers an escalation? Get that documented and signed off before configuring a single thing. It sounds like it would slow you down. It doesn’t. It’s actually the fastest path.
I’d pick the “most ready” market for the first rollout, not the “most strategic” one. We rolled out to our first market ten months after kickoff, with the remaining markets following at roughly one-month intervals. That phased approach was right. But the first rollout is where you learn everything. You want your most enthusiastic, most digitally mature country team going first, so they can become internal champions and help pull the others along.
Three Questions Worth Asking
If you’re running pricing for a food company across multiple markets, I’d encourage you to pressure-test your current state:
How many distinct pricing processes do you actually have? Not how many you think you have. How many actually operate in practice? Count every market, every business unit, every channel. If the number surprises you, pay attention to that.
Can you trace the full approval chain for any price change in the last twelve months? Pick one at random. A discount granted to a mid-tier customer in your second-largest market six months ago. Can you see who proposed it, who approved it, what the margin impact was, and whether it was within policy? If answering that requires phone calls and digging through email, your governance has gaps.
What’s your pricing cycle time, from decision to market execution? When commodity inputs move 15%, how long until your prices across all markets and channels reflect the new reality? During that lag, you’re either absorbing margin or losing share. Usually both.
If any of those made you pause, you’re in good company. The path forward is clearer than you might think. But it starts with process, not software.
Client details are anonymized. The engagement described is a single project and its outcomes are specific to that organization, not a benchmark. No figures in this article are presented as industry averages.