There is a pattern that repeats itself with striking frequency in organizations of different sizes, industries and levels of analytical maturity. Highly sophisticated teams in operations, with robust financial processes and well-defined business structures, end up sustaining a critical part of their decision-making on tools that, in essence, were not designed for that purpose. And yes, I'm talking about the ubiquitous Excel.
This is not criticism of Excel as a tool. In fact, Excel has been, for decades, one of the most important enablers of financial analysis, modeling, and operational control within companies. We all started using Excel, well, I started with Lotus 123 in my last year of school. The problem does not lie in the tool itself, but in the role assigned to it within the decision-making system. When Excel goes from being an analysis tool to becoming the core of the pricing process, the organization begins to build on a foundation that does not necessarily support the complexity, speed, and traceability that the process demands.
Based on this premise and reviewing an article published by Pricefx (at the end I leave you the link in case you want to read it), this article raises a series of reasons why companies should consider migrating from Excel to specialized pricing solutions. Beyond the specific recommendations, the relevance of the approach is not in the technical comparison between tools, but in the implicit evidence of a deeper structural problem: many organizations continue to understand pricing as an operational exercise, when it is a strategic capability.
From this perspective, this article does not seek to replicate the arguments of the original text, but to use them as a starting point to explore a broader question: what happens within an organization when pricing is managed with tools that were not designed to support high-impact strategic decisions?
>> What is RPA and what is it used for? <<
In many organizations, using Excel to define pricing is not a conscious decision, but the result of incremental evolution. The process starts with a relatively simple model: a sheet that consolidates costs, margins, and some basic business variables. Over time, that sheet grows, becomes more complex, (I say leaf, but most of the time it is a book with many pages intertwined with each other), incorporates new conditions, exceptions, specific rules for customers or segments, until it becomes an artifact difficult to understand even for those who built it.
This organic growth is often perceived as a sign of maturity. The "has it all" model, contemplates multiple scenarios and reflects the reality of the business with a considerable level of detail. However, it is this same complexity that introduces fragility. Each new formula, each link between sheets, each manual adjustment increases the risk of error, but, above all, reduces the organization's ability to understand how decisions are being made.
This implies that the problem is not the tool itself, but the lack of an explicit design of the pricing system. Excel ends up occupying that space not because it is the best option, but because it is available, flexible, everyone uses it and allows you to move quickly without the need to define a formal architecture. In other words, it is built as it goes.
From this perspective, the discussion about whether to migrate to pricing software loses depth if the fundamental question is not first addressed: what role should pricing play within the business model?
Pricing has ceased to be, in many sectors, an exercise based solely on costs plus margin, the typical Cost Plus as it is popularly known. The increasing availability of data, competitive pressure, and customer sophistication have transformed pricing into a dynamic system that must integrate multiple dimensions: demand behavior, elasticity, segmentation, business conditions, cost variations, positioning strategies, and financial objectives.
Managing this complexity in a tool designed for tabular calculations introduces a tension that is difficult to resolve. Excel allows you to represent this reality, but not necessarily manage it efficiently. The difference is subtle but critical. Representing implies being able to model a situation, on the contrary, managing implies being able to operate it in a consistent, controlled and scalable way.
That said, many organizations end up operating pricing models that are conceptually correct, but operationally unfeasible. The model exists, but its execution depends on manual processes, informal validations, and tacit knowledge distributed across the team. This not only limits the speed of response, but introduces inconsistencies that erode the impact of the model. I remember a case where an adjustment in tariffs had to be made in almost 600 Excel files. Updating the model was a nightmare.
From this perspective, the argument in favor of pricing software is not only technological, but structural. It is about recognizing that the level of complexity achieved by pricing in certain organizations is no longer compatible with generalist tools designed in-house.
One of the less visible, but most relevant, effects of the intensive use of Excel in pricing processes is the loss of traceability. In practice, this translates into a question that few organizations can answer clearly: why is a specific customer priced the way they are today?
Answering this question requires reconstructing a sequence of decisions, adjustments, exceptions, and validations that, in many cases, are not documented in a structured way. File versions multiply, changes are made without formal control, and the logic of the model is fragmented among different people.
This implies that pricing ceases to be an auditable system and becomes a set of accumulated decisions. The organization may know what prices it has, but not necessarily why it has them. And when you don't understand why, you lose the ability to adjust precisely. So any attempt at optimization becomes more complex. It is not based on a clear model, but on a reality that must be interpreted before it can be transformed. This phenomenon is not exclusive to Excel, but that's where it's most common to see.
In environments where market conditions change rapidly, the ability to adjust prices in an agile manner becomes a competitive advantage. This doesn't mean reacting impulsively but having the infrastructure in place to evaluate scenarios and execute changes quickly and accurately.
Using Excel introduces friction into this process. Each adjustment may require manual intervention by multiple people, validation of multiple versions of the file, and verification that changes do not lead to inconsistencies elsewhere in the model. This cycle, which can be manageable in low-frequency contexts, becomes problematic when speed is important.
This implies that the organization not only responds slower, but in some cases, chooses not to respond. The operating cost of adjusting can be so high that you choose to maintain suboptimal prices, even when the available information suggests the need for change.
In many Excel-based pricing models, there is one key figure: the person who "understands the file." This person not only knows the logic of the model, but also its exceptions, its limitations, and the historical decisions that have shaped it. In many cases that Excel is "your baby" and you will defend it tooth and nail to prevent it from "dying" – being replaced.
While this knowledge is valuable, its concentration on specific individuals introduces structural risk. The organization depends on the availability of those people to operate and evolve the model. Any change in the team, whether due to rotation, growth, or restructuring, can affect the continuity of the process.
This implies that knowledge is not institutionalized but encapsulated. And when knowledge is not formalized, the ability to scale is limited. New team members face long learning curves, and consistency in execution becomes difficult to guarantee. Here we end up depending on a person with all the risk that this entails.
Pricing does not operate in isolation. It is connected to sales systems, ERP, CRM, analysis tools and, in many cases, external platforms that provide market information. The ability to integrate these data sources seamlessly is critical to building a robust pricing model.
Excel allows for some level of integration, but let's face it, it usually requires intermediate solutions, manual processes, or ad hoc developments. This introduces points of failure and limits how often data can be updated.
That is why the pricing model can operate with outdated or incomplete information, which affects the quality of decisions. The organization may have access to relevant data, but it is not necessarily able to incorporate it efficiently into its pricing process.
One aspect that is often underestimated in the discussion of tools is governance. Defining who can modify prices, under what conditions, with what approval levels, and with what validation criteria is important to maintain model consistency.
In Excel-based environments, these mechanisms are often informal. Rules exist, but they are not always implemented in the tool. Control depends on external processes, manual reviews or good practices of the team and above all the person "who understands the file".
This implies that pricing consistency depends largely on operational discipline. And when the volume of decisions increases, maintaining that discipline becomes increasingly difficult.
At this point, it might seem that the solution is obvious: to adopt a specialized tool that solves the limitations of Excel. However, this conclusion, while partially correct, can be a bit misleading.
The tool, by itself, does not define the quality of the model. If the organization is not clear about its pricing drivers, business rules, strategic objectives, and governance mechanisms, the software will simply replicate the same limitations in a more sophisticated environment. We automate clutter, as we often say.
This implies that migration must be understood as part of a broader process of redesign. It is not about moving the existing model to a new platform, but about rethinking how pricing is built, executed and controlled within the organization.
Ultimately, the discussion about Excel versus pricing software is the reflection of a deeper conversation about the role of pricing in the organization. As long as it is understood as an operational process, any tool that allows you to calculate prices will suffice. But when it is recognized as a strategic capability, the demands change.
Pricing is no longer seen because of costs and becomes a tool to capture value. This involves understanding several things such as custproposition andss to pay, segmenting effectively, designing pricing structures consistent with the value proposition, and aligning decisions with the company's financial goals.
This level of sophistication requires not only the right tools, but also a different way of thinking. It requires integrating pricing into the strategic conversation, allocating resources to it, defining clear responsibilities, and building an architecture that supports its evolution.
>> How to drive and revolutionize sales with AI-generated strategies? <<
Returning to the starting point, the Pricefx article outlines a series of concrete benefits of migrating from Excel to pricing software as part of a broader digital transformation process. These benefits are real and, in many cases, relevant. However, as explained earlier, focusing solely on the tool can lead to an oversimplification of the problem.
What is at stake is not just operational efficiency, but the organization’s ability to make decisions that are consistent, traceable, and aligned with its strategy and digital transformation agenda. Excel may be sufficient in certain contexts, but it can also conceal limitations that, over time, impact business performance.
The question, therefore, is not only whether the tool should be changed, but more importantly whether the current pricing model reflects the complexity, ambition, and reality of the business within a digital transformation environment. And, consequently, whether the supporting infrastructure is capable of meeting that responsibility.
Answering this question requires more than a technical assessment. It involves revising assumptions, questioning entrenched practices, and, in many cases, recognizing that what worked in the past will not necessarily be enough to sustain the future. Have you asked yourself these questions in your company? I leave you the link to the original Pricefx article.