Request for quotation (RFQ): meaning and process

The RFQ presupposes that the requirement has already been settled. What is to be procured, in what quantity, in what quality and by when is defined; the only open question is on what terms. That is exactly the difference from the two related types of request with which it is regularly confused.

Distinction: RFI, RFP and RFQ

In practice the boundaries blur. An RFQ is often sent out even though the specification is still incomplete – with the result that the incoming quotes are not comparable, because each provider fills the gaps differently. A second pattern is the staged approach: RFI for a market overview, RFP for selecting a solution, RFQ for pricing with the remaining providers. For standard items and repeat purchases, this chain collapses into the RFQ alone.

The RFQ process

A properly managed process consists of a few but clearly separated steps:

• Specify the requirement: item or service, quantities, technical requirements, standards, quality certificates, delivery date and place of delivery are laid down. This step determines the quality of the entire process.
• Define the group of suppliers: selection from the supplier base or expansion to include new providers, often combined with prequalification.
• Send the request: all suppliers receive the same documents, the same deadline and the same contact person. Deviations from this make the later comparison open to challenge.
• Question phase: questions from individual providers are collected and the answers ideally made available to all, so that nobody gains an information advantage.
• Receive and check quotes: a formal check for completeness, followed by a comparison of content and price.
• Evaluate and negotiate: besides price, delivery time, payment terms, warranty and security of supply are taken into account. Rounds of negotiation may follow.
• Award and conversion: the accepted quote becomes an order or a framework agreement. Rejecting the other providers is part of the process.
• Documentation: the request, quotes, evaluation and decision are filed in a traceable way – mandatory in regulated environments, and in mid-sized companies a protection against discussions after the event.

Data points of a clean request for quotation

Whether an RFQ produces comparable responses depends on the information supplied with it:

• Unique item identification: your own item number, the supplier's number and, where available, a standard identifier such as the GTIN.
• Quantity and unit of measure, supplemented by tiered quantities if price tiers are expected.
• Technical specification, drawings, standards and required certificates.
• Delivery date or delivery period, place of delivery and the desired Incoterms.
• Deadline for quotes and the validity period of the quote.
• Payment terms and currency.
• Contact person and the desired return channel.
• Reference to the applicable terms of purchase.

If the validity period or Incoterms are missing, a price comparison quickly becomes spurious precision: two quotes then differ not in price but in who bears freight and risk.

RFQs in e-procurement and in the B2B shop

Traditionally, the RFQ ran via email and spreadsheets. With the digitalisation of procurement, it is moving in two directions: into the procurement systems on the buying side and into the sales systems on the supplier side.

On the buying side, e-procurement systems map the process as a structured workflow – with approval levels, deadlines, automatic quote comparison and audit-proof filing. On the supplier side, the counter-movement is taking place: the B2B online shop takes over the role that inside sales previously played in the inbox.

In a B2B shop this typically looks as follows: instead of or alongside the buy button, a quote request is available – from the product view for individual items or from the basket for a whole selection. The customer adds items, fills in quantities and notes and triggers a request from them. On the retailer side, the request appears in the administration, is checked, given prices, discounts and shipping costs and sent back. The customer accepts, rejects or negotiates further. If it is accepted, an order is created directly from it – without items having to be entered again.

The gain lies less in speed than in data quality. A request created from the basket contains valid item numbers, correct units of measure and the terms stored for this customer. A request written in an email contains item descriptions in the customer's own words, which someone has to match manually.

A real-world example: quote management in Shopware

A concrete, traceable example is the B2B Components of Shopware 6 with their quote management. B2B customers can request an individual quote for the content of their basket there; the retailer sees the request in the administration, edits it and sends it back. During the quote process, comments and discounts can be set on individual items, shipping costs added and changes traced via a history. Extended status values and notifications make the processing status visible to both sides. The range of functions is described in the Shopware documentation on quote management.

What is remarkable is that the loop is closed: the request, processing, response and conversion into an order run in the same system and on the same data. It is precisely this point that distinguishes a digital RFQ from an email sent via a form that is then retyped manually after all.

Interfaces: PunchOut, OCI and EDI

As soon as the purchasing and sales systems are supposed to talk to each other, established standards come into play.

With PunchOut – in German-speaking countries usually implemented via the OCI interface – the buyer jumps out of their procurement system into the supplier's shop, puts together a basket there and transfers it back into their own system. The big advantage: the catalogue is no longer maintained as a file but used in its current version at the supplier, while approval and ordering remain in the buyer's system. In this model, depending on the set-up, the basket transfer can also be treated as a quote request rather than a direct order.

EDI (electronic data interchange) addresses structured message transmission between systems. In the widely used UN/EDIFACT standard, there are dedicated message types for request and quote – REQOTE for the request, QUOTES for the quote, ORDERS for the order. Where this chain is put into practice, all manual entry is eliminated. An introduction to the standardisation of these message formats is provided by the overview of EDIFACT.

For mid-sized companies, the practical order is usually: first the shop with a quote function, then PunchOut for the larger customers, and EDI only where volume and frequency justify the effort.

Typical mistakes

• Incomplete specification: the most common mistake. It produces quotes that cannot be compared and shifts clarification into the negotiation phase.
• Unequal distribution of information: if one provider receives additional information on request that the others do not, comparability is gone.
• Too many suppliers asked: a widely scattered request ties up capacity on both sides. Providers who are repeatedly asked without a chance will give future requests correspondingly lower priority.
• Price comparison without additional costs: freight, packaging, small-quantity surcharges, payment terms and currency risk regularly change the ranking.
• Missing validity period: without it, it is unclear how long the quote is valid – a problem as soon as decision-making takes longer than expected.
• Media break during conversion: if the accepted quote is transferred manually into an order, that is exactly where transposed digits arise.
• No rejection: leaving unsuccessful providers without a response costs nothing – until the next request.

Relevance for mid-sized retailers

For manufacturers and wholesalers, the incoming RFQ is often the real bottleneck in sales. Requests come in via forms, emails and phone, are manually turned into quotes by inside sales and then transferred to the ERP system. Each of these steps costs time and creates sources of error, and none of them produces data that can be analysed. Anyone who brings the quote request into the shop shifts entry and follow-up to where the item master data and customer terms are kept anyway. Inside sales then calculates and negotiates instead of copying out items.

A side effect concerns range policy: analysed requests show which items are regularly requested but not ordered – an indication of price, availability or specification problems that remains invisible in the email inbox.

Outlook

Two developments are emerging. First, the increasing automation of quote creation: where pricing logic, availability and discount rules are stored cleanly, a considerable proportion of requests can be answered without manual processing, so that inside sales can concentrate on the exceptions. Second, closer integration of request and contract: framework agreements, call-off quotas and recurring requirements are increasingly maintained from the request data instead of being negotiated separately. The basic mechanics of the RFQ – defined scope, comparable quotes, documented decision – remain unaffected.

FAQ

Is a request for quotation legally binding?

Under German law, the request itself is usually not a binding declaration of intent but an invitation to submit a quote. What typically becomes binding is the supplier's quote within its validity period and its acceptance. The specific classification depends on the wording and the underlying terms.

How many suppliers should you ask?

As many as necessary to get a reliable comparison, and as few as possible to limit the effort on both sides. For standard items, a few qualified providers are usually enough; for critical items, security of supply is added as a separate criterion.

How does an RFQ differ from a tender?

The term tender is used above all in public procurement and is bound to formal procedural rules there. The RFQ is the more general, private-sector process; it can be conducted in a formally strict way, but does not have to be.

Can a shop offer quote requests and direct ordering in parallel?

Yes, and that is the norm in B2B. Standard items with a stored customer price are ordered directly, while special items, large quantities or project-related selections go through the quote request. What matters is that both routes work on the same item master data.

What must at least be included in a response to an RFQ?

Price per item and total price, unit of measure, delivery time, delivery terms, payment terms, validity period and a clear reference to the request. Deviations from the specification must be named explicitly and not silently factored in.