CPQ vs ERP for Quoting: Buy, Build or Combine

The email arrived on a Wednesday from the managing director of a custom label and overlay maker in central Europe. Quoting ran on a spreadsheet and one experienced estimator who was near retirement, and the third of his three questions was the one every owner and IT lead ends up asking: existing software, a custom build, a combination, or something else. Two vendors had already framed it for him as CPQ vs ERP, pick one. Both were wrong for his business, and I told him so by email before we ever spoke, along with the names of the print industry systems he should actually call.

This piece is the long version of that reply, for the person who owns a quoting process that has stopped working and now has to decide what to put in its place. It is written by someone who builds the third option, so read it with that in mind. It sends a lot of readers to the first two.

In brief

• CPQ vs ERP is the wrong first question. The right one is what your quote starts from: a part you have made before, a product the customer can pick from a list of options, or a document somebody else wrote describing a thing that does not exist yet.
• An ERP quoting module prices the first case well, a configure price quote system prices the second well, and neither reads the third. Reading is where the money is decided on engineered work, and it is the station no product category covers.
• Most implementations that stall do so for a reason that has nothing to do with the software: the pricing rules were never written down, and the software project turns into a rule capture project in month six.
• Build is a real answer for one product family with written rules and an owner. It is a bad answer for a group.
• Combine is the usual honest answer for a company with more than one kind of product: the ERP for repeats, a configurator for standard lines, a reading step, a person or an engine, for engineered lines, and one written pricing identity across all of them.

What a quoting system actually is

Before comparing two categories of software it helps to say what the thing they are supposed to replace looks like. A quoting system is whatever carries a request from arrival to a number on a bid form. In a custom manufacturer it has nine stations, which I described in detail in the manufacturing quoting process guide: the request arrives, usually as a document written by somebody else; a bid or no bid decision; reading the document for every sentence that changes the price; deciding scope and assumptions where it is silent or contradicts itself; the cost build; the price; review; submission; and feedback, when the job is built and the actual cost is known.

In most companies the system that covers those nine stations is not software. It is an inbox, a spreadsheet and a person, and the person carries stations two through six in their head. When that person is near retirement, or when volume has outgrown them, the company goes looking for software, and the two categories it finds first are the enterprise resource planning system it already owns and a configure price quote product a salesperson is happy to demonstrate.

Both are real answers to real problems. The mistake is treating the choice between them as the decision, when the decision is which stations you need covered.

The two problems hiding inside the word quoting

The label maker's email taught me something I now ask about on every first call. There are two different problems that both get called quoting, and they need different systems.

The first is working out what needs pricing. The customer has sent a document, and somewhere in it is the list of things you will have to make, buy, test and deliver, with the requirements that change what each one costs. On engineered work this is most of the job, and it is where the expensive mistakes are made: the sentence on page nine that doubles the steel, the standard cited in passing that adds a test, the foam system the specification carries and the purchase description does not.

The second is deciding how to make it and what that route costs. The list of things is known. The question is which machines, in which order, at what rate, with what scrap, and the answer is a routing and a cost model. This is the label maker's whole problem. His jobs are small, numerous and technically known; a label goes through screen printing or digital, die cutting, lamination, finishing, and the price is the sum of those steps at his machine rates. The print and converting industry has had management information systems that price exactly that for decades, and they are the right answer for him, not a CPQ, not his ERP's quote screen, and not us.

Most engineered manufacturers have both problems, and the reason the CPQ vs ERP framing fails them is that both categories answer only the second. Keep the two apart when you read any vendor's proposal, and ask which one the demo just solved.

CPQ vs ERP: what each one is built to do

Plain words first. An ERP, an enterprise resource planning system, is the company's system of record: parts, bills of material, routings (the sequence of operations a part goes through and the time each takes), inventory, standard costs, orders and invoices. Most ERPs sold to manufacturers, from Epicor and Infor to NetSuite and SAP, carry a quoting or estimating module that lets you build a quote from those records: pick the part or a similar one, roll up the material and the routing at standard cost, apply a margin, print a quote document, convert it to an order when it is won.

A CPQ, a configure price quote system, is built for a different job: selling a product that comes in many valid combinations. The customer, or a salesperson, chooses a model, a size, a finish, options; a rules engine prevents invalid combinations; pricing rules and discount approvals produce the number; a document generator produces the proposal. Salesforce, Oracle, SAP, Tacton, Epicor CPQ, Experlogix, Configure One and a dozen others sell it, and for the product it is built for it works very well. I have said so before in our buyer guide to AI quoting software, against our own interest, and it is still true.

Put them against the nine stations and the shape of the problem appears. The table uses three words: covers, partly, and no. Partly means the system does part of the station, or does it only when a condition holds that I explain below.

Read down the ERP column and it is a cost build and submission tool. Read down the CPQ column and it is a configuration, pricing and approval tool. Read across the reading row and the scope row and there is nothing in either column. That row is where engineered work is won or lost, and it is the row the label maker's two vendors never mentioned, because their products do not have it.

When the ERP quoting module is enough

If most of what you quote is a part you have made before, or a close cousin of one, the module you already own is probably the right answer and the cheapest one. The quote is an order that has not been placed yet. The part has a routing, the routing has times, the material has a standard cost, and the estimator's job is to pick the closest part, adjust the quantities, check the material price is not stale, and apply the margin. An ERP does that well, and it does one more thing nobody else does: when the job is built, the actual cost lands in the same system as the quote, so feedback is possible even if almost nobody runs the report.

The test is a share. Pull the last hundred quotes and count how many were for a part with an existing part number and routing, or something close enough that the routing was copied. If it is eighty out of a hundred, stop reading and go and configure the module properly. The failure mode is what happens to the other twenty. The estimator builds them in a spreadsheet, because the part does not exist in the ERP yet, and types the total into the quote screen. The ERP then carries a number it cannot explain, and the spreadsheet carries the rules the ERP was supposed to hold. That is how a company ends up with a quoting module that is live, paid for, and used as a printer.

The other limit is plants. An ERP holds one set of standard costs per site, and if four plants quote the same product family with four lineages of workbook, the module will faithfully record four different answers to the same question. That is not the software's fault. It is a rule problem, and I will come back to it.

When CPQ is the right buy

If the customer can choose the product from a list of options without an engineer in the room, buy a configurator and do not let anyone talk you into anything else. Standard product lines with real option lists, pumps in six sizes and three materials, enclosures with a menu of cutouts and finishes, a catalogue of frames with lengths and loads, dealer channels that need to quote without calling the factory: this is exactly what CPQ was built for, and the mature products have twenty years of rules engines, pricing logic and proposal generation behind them. The eight tool comparison on this site says the same thing tool by tool.

The test is the engineer. Watch a quote for your most standard line from request to number and ask whether anybody had to make an engineering decision. If the answer is no, CPQ. If somebody had to open a drawing and decide whether a load, a pressure, a footprint or a paragraph of somebody's specification could be met, and how, you have left the configurator's territory, and no amount of rules will bring you back, because the rules would have to anticipate a document nobody has written yet.

CPQ also carries two costs people underestimate. The rules have to be written, every valid combination and every price consequence, and that is a project whose size is set by your catalogue, not by the vendor. And the product is only as current as the last time somebody updated the rules, so it needs an owner, indefinitely. Both are fine for a standard line with a product manager. Both are fatal for an engineered line where every job is a new combination.

How CPQ and ERP work together, and where the seam breaks

Nobody runs a CPQ instead of an ERP. The configurator sits in front of the system of record, and the two exchange data in both directions. Going in, the CPQ needs the ERP's item master and standard costs, or a copy of them, so that a configured product prices against real material and labour rather than a list somebody typed into the configurator two years ago. Coming out, a won configuration has to become an order, a bill of material and a routing in the ERP, and the good integrations generate all three from the configuration rules rather than having somebody re-key them. When that works, the company has one price for a product wherever it is quoted, and the factory receives an order it can build without a phone call.

The seam is the costed bill of material, and it is worth knowing exactly where it breaks. It breaks first on the standard costs, which drift: the ERP's plate price was updated in January, the configurator's copy was not, and the two systems now quote the same tank at two prices, and nobody notices until the margin report. It breaks second on the engineered job. A customer asks for the standard tank with a nozzle the configurator does not offer, sales adds a text note, and the order arrives in the ERP as a configured product plus a sentence. Engineering prices the sentence by hand, in a spreadsheet, and the integration everyone paid for now carries a number it did not produce.

Both breaks have the same cure, and it is not more integration. It is an owner for the rates, with a written rule for when they are refreshed, and a decision, made in advance, about which product lines are configured and which are engineered, so that the engineered job is never forced through the configurator's text box. The first is a rule. The second is the combine answer, and I will come to it.

Where both stop: the document somebody else wrote

The reason CPQ vs ERP is the wrong question for engineered work is that both categories assume the quote starts from your own data. The ERP starts from your part. The CPQ starts from your catalogue. An engineered quote starts from a document written by a consulting engineer, a contractor or a purchasing department, in which your product is a minority of the pages and the thing being priced has never been built.

I have read a lot of those documents for this site, all of them public. A fire district's request for a pumper truck ran 99 pages, of which 84 were a compliance matrix: a paragraph, and a YES and a NO to circle, roughly three hundred times. Its warranty section contradicted itself, and the specification carried a foam system that the purchase description did not order. A federal bridge crane specification covered a 100 ton crane in 27 pages that cited 43 standards and required 31 approved submittals, and an amendment changed the drives and left the rest of the document as it was. A 668 page municipal wastewater package carried its requirements for one piece of process equipment in 14 sections spread through the book. A 179 page marine package had the freeboard datum in one place and the deck load in another and did not say which governed.

None of that is a configuration. None of it is a part number. It is reading, and then scope decisions where the document is silent or disagrees with itself, and both of those happen before a single cost line exists. In the spreadsheet company those two stations live inside the estimator, which is why the company is fine until the estimator is not there. In the ERP company they live in the spreadsheet beside the ERP. In the CPQ company they live in the engineer who is called in to help configure the job that does not fit, which is the polite name for pricing it by hand.

A reading engine is the category built for that row: software that takes the whole package, finds every sentence that changes the price, ties each to its page, puts the contradictions and the silences in front of a person, and only then builds cost in the company's own rules. It is what we build, and I describe how it works and how to test it in the buyer guide and the pilot protocol. It does not replace the ERP's cost roll up or a configurator's rules engine. It sits in front of them, at the station they skip.

Why implementations stall in month six

Whichever way the decision goes, the projects that fail tend to fail the same way, and it is worth knowing the shape before you sign anything. The software is installed, the integration to the ERP works, the demo data prices beautifully, and then somebody tries to load the company's actual pricing rules and discovers they do not exist in a form that can be loaded. The margin rule is one line in an estimator's head that depends on the customer, the backlog and the mood of the month. The scrap allowance is a percentage somebody adds for now. The plate price is a supplier email from fourteen months ago. The software project becomes a rule capture project in disguise, discovered in month six, after the licence is signed.

I wrote about where those rules live and how to get them out in the tribal knowledge piece, and the short version applies to every option in this article: if the rules cannot be written down, no system will hold them, and the order of work is rules first, software second. The one useful instrument before any purchase is a quote genealogy, which traces every number on one finished quote to its source and reports how many of those sources are written anywhere. Companies that run it are usually surprised, and the surprise is the real scope of the project they are about to buy.

The cost of skipping this is not abstract. Thirty two public custom manufacturers describe the same risk to their investors in their annual reports, which I read for the fixed price contract risk piece: if the cost estimate made at the quote proves inaccurate, the difference comes out of margin. Textron put a number on one programme, an expected charge of sixty to a hundred and ten million dollars from when the program was bid. The estimate that produced it was made at stations three through six, by people, using rules that were, in most such companies, never written down. No category of software fixes that on its own. Writing the rules down does, and then the software has something to hold.

Build: when it is the right answer

Build is a real option now in a way it was not five years ago, and I say that as a vendor. A general purpose language model, a folder of past quotes and a weekend will get an estimator a working assistant that reads a specification and drafts a requirements list, and I published the recipe, the instruction rules and the blind test to score it in the ChatGPT quoting assistant piece. Sometimes that article answers build, and it means it.

Build is right when four things are true at once: one product family, so there is one set of rules to write; rules that are already written or can be written in a run of afternoons with the estimator; low enough volume that a person reviews every output; and an owner, somebody whose job now includes maintaining the thing when rates move and the model changes. A ten person shop with one family, a good estimator and a curious engineer meets all four, and should build before buying anything.

Build is wrong when any of the four fails, and the one that fails first is the owner. The five walls I described in that piece, in the order you hit them, are the document that does not fit in the model's working memory, the drawing the model cannot read, the rule the model applies inconsistently, the rate that expired silently, and the second estimator who does not trust the first one's instructions. Each is crossable. Crossing all five is a product, and now you own a product, with the maintenance that implies, in a company whose business is making something else. The reason quoting is hard to automate is that it has none of the feedback loops software development takes for granted, and a home built system has to add them by hand.

Combine: the usual honest answer

Most companies large enough to be asking this question do not have one kind of quote. They have a standard line that sells from a catalogue, a repeat business of parts made before, and an engineered line where every job starts from somebody else's document. The honest system is different at each, and the mistake I see most often is buying one category and forcing all three through it. The configurator gets a custom option that opens a text box. The ERP gets a miscellaneous part that carries the engineered jobs as one line with a typed total. The engineered line's rules disappear into whichever workaround was chosen.

Combine means drawing the boundary by what the quote starts from, per product line, and giving each lane the system built for it: the ERP module for repeats, a configurator for the standard line, a reading step for the engineered line, which is an engine if the volume justifies it and a measured, written reading step done by a person if it does not. Then the part that makes the whole thing worth doing: one written pricing identity across all three lanes, the same margin logic, the same rate eras, the same scrap rules, so that the margin report at the end of the year is comparing like with like. Without that, combine is three systems and three opinions about what the company's price is.

Here is what it looks like at a composite of the two plant companies I have looked at, with the details changed. Plant A makes a catalogue of standard tanks in fixed sizes and sells most of them through distributors. Plant B makes custom vessels from a customer's specification, thirty a year, and a fifth of its revenue is one job. Today both quote in workbooks with different lineages and the group's margin figure is a blend nobody can decompose. The combined system is a configurator for Plant A, fed by the ERP's standard costs so distributors can quote without calling; a reading step for Plant B that produces a requirements list with page numbers before any costing begins, with the cost build done in the ERP's estimating module against the same standard costs; and one pricing identity document, written with both plants' estimators, that the configurator's rules and Plant B's estimator both apply. The seam between them is the costed bill of material in the ERP. Everything hands off there.

Notice what the group did not buy: a second ERP, a CPQ for Plant B, or a custom build. And notice what it did have to do first, which was write the rules down.

Eight questions that decide the lane

These are the questions I ask on a first call, in this order, and the answers usually settle the CPQ vs ERP question early, along with whether either applies at all.

1. What does the quote start from? A part number, a list of options, or a document written by somebody else. This is the whole decision in one question; the rest are checks.
2. Of the last hundred quotes, how many were for a part you have made before? Above eighty, the ERP module. Below twenty, it is not your quoting system, whatever it says on the licence.
3. Can the customer choose the product without an engineer? Yes, and CPQ is right for that line. No, and it is not, for that line.
4. How many pages is a typical request? Four pages is a form. Ninety nine pages is a reading job. Six hundred is a reading job that decides the margin.
5. How often does the document contradict itself, and who notices? If the answer is the estimator, usually, you have found where the scope station lives.
6. Are the pricing rules written anywhere a new hire could find them? If no, the first project is not software. It is rule capture, and every option in this article waits on it.
7. How many estimators, and how many plants? One and one can build. Four plants with four workbook lineages need the pricing identity before they need anything else.
8. Do you know quoted versus actual cost on the last ten won jobs? If nobody can answer in an afternoon, the feedback station does not exist, and the first win from any system is building it.

If you would rather score it than talk, the quoting system health check asks twelve questions across the same ground and puts you in a lane without asking for an email address.

Three questions to ask on any demo

Every category in this article demos well, because demos are built on data the vendor prepared. Three questions turn a demo into evidence, and they work on us as well as on anyone else.

First, ask them to run your document, not theirs. Bring the package you least want to read again, the ninety page one with the amendment, and ask the system to find every requirement that changes the price. An ERP quote screen will have nothing to say. A configurator will ask you to pick options. A reading engine should produce a list with page numbers, and if it does not, you have learned what it actually reads. Do this before anyone talks about integration.

Second, ask where the rules live. Not the vendor's rules, yours: the margin logic, the scrap allowance, the rate eras. Ask to see the screen where those are entered, and then ask who at your company is going to enter them and from what source. If the answer is that your estimator will type them in during implementation, ask how many of them are currently written anywhere. That number is the project.

Third, ask what happens when the document contradicts itself. The fire truck specification said one thing about warranty on one page and another thing later. The crane solicitation changed the drives in an amendment and left the rest. Every engineered package has one of these, and the honest answer from any system is that it puts the contradiction in front of a person and records what the person decided. A system that resolves it silently has made a scope decision on your behalf, and it will not be the one you would have made.

What moves the cost of any of the three

I will not put numbers here, for the same reason our pricing page does not: the scope varies more between companies than anything else in this business. But the drivers are the same whichever way you go, and knowing them lets you place yourself before a vendor does it for you. Product families, because each one is a set of rules to write. Plants and estimating teams, because each one is a lineage of workbook to reconcile. Volume, not because anyone should meter documents but because it decides what the system has to carry. Document size, because a four page request and a six hundred page package are different jobs. What is already written down, the one lever you control, and the biggest. And integrations and security review, which add scope and which none of the three needs in order to start.

The one cost that is invisible on every vendor's proposal is the rule capture, and it is the same size whichever option you buy, because it is set by your company and not by the software. Budget for it first.

CPQ vs ERP vs a reading step: the decision in one table

The last row is the label maker. His quotes start from a job specification with a routing across screen printing, die cutting, lamination and finishing, and the print industry's management systems price exactly that, layer by layer. Neither CPQ nor his ERP nor a reading engine was the answer, and the right thing to do was say so.

What we do, and where the audit fits

Mavlon builds reading engines for custom manufacturers, the last column in the station table, and we are the wrong answer for four of the six rows above. That is why the first thing we do with any company is not a demo. It is a quoting system audit: five instruments run on your own quote archive with your estimators, ending in one of three answers, keep what you have with the rules finally written down, buy the category that fits, or build the engine on the archive we have just mapped. We give the first two answers when they are true. We gave the second to the label maker, by email, before any call, and he wrote back.