Three meetings booked, three pricing software vendors, and the same screen filled with colorful charts in each one. After the third demo, most managers walk away feeling they have seen three similar products but still have no solid basis for making a decision. The problem is not a lack of attention: demos are designed to show what works well, never what breaks.
People attending these meetings generally already know which criteria to assess: ERP integration, tax calculations, margin rules, simulations, governance, and implementation time. The list exists and helps structure the agenda. What is missing is something else: the specific question that puts each criterion to the test, and the kind of answer that reveals a polished spreadsheet being sold as a system.
This guide does not replace the list of criteria—it builds on it. What it adds is the question that pushes the vendor beyond the standard pitch, along with the warning sign that the answer is evasive.
Integration isn't just “yes, it integrates”—it's what happens when the ERP changes
The standard question is, "Does the system integrate with my ERP?" Every demo says yes. The question that separates a real integration from a promise is different: how does it work—through an API, a dedicated connector, or a manually exported file—and how often does it run?
Then comes the question most people fail to ask but should: what happens when the ERP is upgraded to a new version? A vendor-maintained connector survives the change; manually exchanging a file every month is not integration—it is merely a process labeled as integration.
You can spot an evasive answer by the verb tense: when the salesperson describes the integration in the generic present tense ("the system connects to the ERP") instead of walking you through the process step by step, they have probably never had to explain it to a technical client. Ask to see the integration setup screen, not the slide about it.
Tax per item, not the spreadsheet's average tax
No Brazilian pricing software provider will say it ignores taxes. The right question is not whether the software calculates them, but how it calculates them for each item: ICMS and ICMS-ST using the destination state's MVA, PIS and COFINS based on the company's tax regime, and IPI where applicable, using the NCM and CFOP already on file.
A quick way to test this during the demo is to ask the salesperson to calculate, live, the price of a product your company sells in two different states, each with a different MVA. If the answer is "we can adjust that manually later," the system treats tax as an average percentage—exactly what a spreadsheet already does.
This matters because a tax error directly affects the margin without warning. Consider an item that costs R$ 200.00, with a planned markup of 40% on cost:
- Price calculated using the correct markup: 200 × (1 + 0.40) = R$ 280.00
- If the system underestimates the actual tax burden by 2 percentage points, the final price includes a tax that has yet to be paid—and the margin management believes it has differs from what the business can actually sustain, even if the markup formula is correct on paper.
The problem isn't the calculation. It's the data that went into it.
Margin rules that hold up under exceptions, not just the general rule
Every demo shows off the polished screen for setting margins by product family. The question that separates a system from a spreadsheet is how it handles exceptions: what happens to an item that does not fit into any registered family, or to a customer who negotiates outside the standard price list?
It is also worth asking whether margins can vary by channel and sales velocity within the same product family. An entry-level item and a long-tail item can rarely support the same margin, and a system that only allows fixed minimum and maximum margins by category pushes the manager back toward the arbitrary averages the formula was meant to avoid.
A single margin for everything is the clearest sign that the calculation is disconnected from what actually drives the price—cost, competition, or the value customers perceive. Pricing software should allow for this variation without creating chaos; if it cannot, the only difference from a spreadsheet is visual.
Simulation, governance, and timelines: where evasive answers are most common
Three questions round out the script, and vague answers are common for all three:
- Simulation before publishing to the store or applying to an order: can you see how a new price will affect margin, revenue, and your competitive position before applying it, or is the price sent straight to the catalog?
- Governance over who approves what: are approval levels defined by user and group, with a record of who changed what and when, or can anyone with system access change any price?
- Time to first published price: how many weeks until the operation is actually up and running, not how many weeks until the contract is signed?
For all three, a salesperson who gives a specific timeline and screen name has been through a real implementation. One who says “it’s quick, don’t worry” or “it depends on your internal process” is describing the product they would like to sell, not what your team will actually encounter in the first month of use.
A Roadmap, Not a Verdict
None of these questions is enough to rule out a vendor on its own. The value of the guide lies in comparison: asking the same question in all three meetings reveals who responds with a process and who responds with a slide deck. After the third demo, anyone who used this guide will leave not with the sense that they saw three similar products, but with a table of specific answers to compare—which is exactly what most pricing software purchasing decisions lack.
The full criteria, including all six starting points, are available in pricing software. And the reasoning behind each of these questions—why incorrect tax calculations erode margins, and why a single margin is a sign of a formula disconnected from the market—is explained in detail in how to price retail products.
