From RFQ to cash: where manufacturing information gets lost

A customer asks for a price. Sales gathers a drawing, estimating builds a cost, someone approves the quote and an order arrives. Production makes the parts, shipping dispatches them and finance raises an invoice.

On a process diagram, that looks like a sequence. In a working manufacturer, each transition may cross a mailbox, spreadsheet, database, application and conversation. The problems often appear between those places: a revision is missed, a promise is copied without its assumptions or a completed shipment waits for information before it can be invoiced.

Improvement starts by following one transaction through those handoffs. You need to know which record each team trusts, what the next person needs and how an exception becomes visible. That gives you a basis for deciding whether to change a process, improve an existing tool or connect two systems.

This guide follows a fictional request for 250 bronze sleeves. The identifiers, quantities, dates and values are illustrative. They are not a client case study or a benchmark for manufacturing performance.

Start with a record everyone can follow

Our example begins with request RFQ-1042, for part SL-030, drawing revision B. A subsequent quote becomes Q-2081, an accepted order becomes SO-3175, and shipping and invoicing create their own records.

Those records do not need identical identifiers. They need explicit relationships. Someone investigating a disputed invoice should be able to find the shipment, order line and accepted specification without guessing which document name resembles another.

Use the same approach for a product configuration or a custom engineering request. Capture the specification at the point it is accepted, including the revision and the assumptions that affect scope. A live catalog can change later; the transaction still needs to show what was agreed at the time.

Figure 1 — Follow the record and the responsibility. Intake captures the request and revision; estimating records assumptions; approval establishes authority; order entry verifies the commitment; production records execution; shipping confirms dispatch; finance reconciles invoice and payment. A record identifier connects each stage to the next.

1. Intake: collect enough to assign the work

RFQ-1042 arrives with a drawing and a requested delivery date. The first useful question is who owns the response. A mailbox can receive the message without establishing that responsibility.

Define a small set of intake fields that helps the owner decide what happens next. These might include the customer reference, part revision, quantity, requested timing and any missing information. Keep “received,” “needs clarification,” “estimating” and “declined” distinct if those statuses correspond to different actions.

Do not make every possible field mandatory. An early inquiry may legitimately lack final details. A well-designed intake process can distinguish an incomplete request from a complete request that has not been assigned. It can also explain to the customer what is needed before a useful estimate can be prepared.

For sensitive drawings or technical records, agree the appropriate exchange before collecting them. A general website inquiry is a place to describe the need, not an assumption that every manufacturing document belongs in a public form.

A useful first improvement: one owned request record with links to the approved document location. It may coexist with the existing mailbox. The purpose is to avoid losing responsibility when someone forwards a message or takes leave.

2. Estimating: preserve the assumptions behind the price

The estimator reviews revision B, chooses a routing and prepares a cost for 250 sleeves. Material, setup, machining, inspection and any outside processing contribute differently. A quantity change may affect one component without changing another.

If the estimate lives only as a total, the next person cannot see what changed when the customer requests a tighter tolerance. Preserve enough detail to explain the decision: the quantity, specification, material-rate date, routing assumptions and any supplier minimums that matter.

Distinguish the expected production cost from the selling price. A markup is not the same calculation as a gross-margin target. Also distinguish a budget estimate from an approved commercial quote. Those distinctions should be visible in the record and understandable to the person receiving it.

Our product configurator demonstration shows a simple version of this relationship using fictional rates. It is useful for illustrating how dimensions and quantity affect an estimate. It does not establish the right costing method for a particular shop or certify that the illustrated part is manufacturable.

A useful first improvement: a structured estimating worksheet that records assumptions and produces a consistent quote handoff. Automating that handoff can come after the fields and responsibilities are understood.

3. Approval: identify the decision and its authority

Suppose the estimate requires a commercial review before Q-2081 can be sent. “Waiting for approval” should identify a decision, an owner and the version under review. Otherwise it becomes a status that describes delay without explaining how to resolve it.

Decide what changes require another review. A revised quantity, different material or new delivery commitment may invalidate a previous approval. The system should not silently treat an approval of revision B at one quantity as approval of every later variation.

An internal tool can make the pending decision visible and remind the responsible role. It should preserve the distinction between preparing a recommendation and exercising approval authority. Sending a notification is not evidence that somebody approved the change.

Keep a record of the decision appropriate to the business: who acted, when, which version they reviewed and any conditions. The level of control should fit the financial and operational importance of the action.

A useful first improvement: a defined approval record linked to the quote version, with a clear route for reassignment when the normal approver is unavailable.

4. Order entry: reconcile the customer commitment

The purchase order arrives, referencing Q-2081. This is a new checkpoint. The customer may have changed the quantity, included another revision or requested a delivery date that was never offered.

Compare the purchase order with the accepted quote before releasing SO-3175. Determine who resolves a difference and where the resolution is recorded. A copied price and an order number are not enough to prove the specification and delivery commitment agree.

Keep original and revised promises distinguishable. If a date changes, users may need the original customer commitment for performance reporting and the current plan for daily action. Overwriting one with the other makes those questions harder to answer later.

The authoritative system may differ by field. The ERP may own the released order quantity, the controlled document system may own the drawing and the CRM may own the sales opportunity. Establish the relationships rather than declaring that one application owns every fact.

A useful first improvement: an order-entry comparison that flags mismatched revision, quantity, price or requested timing for a responsible person to resolve.

5. Production: connect a constraint to affected work

SO-3175 is released, but material needed for the sleeves is delayed. The purchasing record identifies a supplier commitment. The production schedule identifies an operation. The order book identifies a customer and shipment value.

A useful exception view connects those facts. It should make clear which information is confirmed and which is a planner’s assessment. “Supplier says Friday” and “delivery received” are different events. A report should not flatten them into the same reassuring status.

At-risk value needs a definition. An unshipped order is not automatically at risk. If several constraints affect one order line, summing its full value under every constraint can inflate the exposure. You might choose one primary risk for an executive total while retaining all constraints in the detailed record.

That is a modeling decision, not a universal accounting rule. Explain the rule beside the number and reconcile representative orders before publishing a total. Our executive dashboard showcase demonstrates one such approach with fictional data.

A useful first improvement: a daily exception list linking the affected order, constraint, current evidence, accountable role and next action. A chart is optional; the investigation path is essential.

Figure 2 — Connect records without blurring authority. Sales owns the inquiry and quote relationship, the ERP owns the released order, production records execution, shipping confirms dispatch and finance owns invoice and payment records. A reporting view combines selected facts and displays its refresh time. It does not become the authority for all source data.

6. Shipping: separate finished from dispatched

The sleeves are complete. That does not necessarily mean they can ship. Packaging information, an inspection release, customer delivery instructions or dispatch authorization may still be needed.

Choose statuses that distinguish physical completion, release and confirmed shipment. Then attach the appropriate event to the shipment record. If a package is staged but has not left, a report should not imply a completed dispatch because an earlier step is finished.

Partial shipments deserve explicit treatment. If 150 of the 250 sleeves ship first, preserve both the shipment event and the remaining open quantity. The next team needs to know what was dispatched, what is outstanding and which documents support the movement.

Avoid collecting an enormous list of shipping fields simply because they might matter someday. Identify what the receiving role uses to release work, fulfill the commitment and support the next financial step.

A useful first improvement: a release view that shows which ready orders are waiting for information, who owns the missing item and what evidence confirms dispatch.

7. Invoicing: investigate the gap after shipment

An invoice may depend on shipment confirmation, a customer purchase-order reference, an agreed billing milestone or another business condition. Define those dependencies with finance rather than assuming that every shipment should generate the same immediate action.

Where an invoice is expected, identify the unbilled shipment or missing reference as an exception. Give it an owner. A large “shipped” total can conceal work that the next team has not yet been able to process.

Shipment value, invoiced value and cash received answer different questions. Do not label one as another to simplify a dashboard. Accounting recognition and tax treatment belong to the organization’s accounting policy and professional advice; a reporting tool should preserve those distinctions.

The invoice record should identify the relevant order and shipment or milestone. If a credit or correction is needed, preserve the relationship rather than editing history until the current total looks right.

A useful first improvement: a reconciled list of shipped items awaiting the required billing step, with reasons that finance can confirm.

8. Collections: turn aging into an investigation

An invoice-aging view needs an as-of date, an open balance and an agreed aging basis. Aging from the invoice date produces a different result from aging against the due date. Show which one is used.

A part-paid invoice should not appear as though the original amount remains outstanding. A disputed invoice may need a different next action from an otherwise routine overdue balance. The useful view connects the amount to a reason, supporting records and the role responsible for follow-up.

In our fictional transaction, a customer questions the first shipment quantity. Finance should be able to find the shipment evidence and accepted order without recreating the full inquiry history by email. That is the benefit of connected records at this stage.

Do not automate customer-facing collection messages just because a date crosses a threshold. Agree the policy, exceptions and review authority first. Internal visibility can improve before external communication is automated.

A useful first improvement: an aging list with accurate open balances, dispute context and a clear route to supporting shipment records.

Define the handoff rather than adding another status

Across these stages, a handoff needs a sender, a receiver and enough information to proceed. A status such as “done” may be meaningful to the sender while leaving the receiver unable to act.

For each transition, answer four questions: what event makes the work ready, what information must travel with it, who accepts it and what happens if something is missing? Add the source record and revision when those affect the decision.

The exception path matters as much as the normal path. An integration can encounter an unavailable system, an invalid reference or a duplicate delivery. Specify whether it should retry, hold for review or stop, and make the result visible. Avoid a design that leaves users uncertain whether they need to re-enter the transaction.

Figure 3 — Route exceptions deliberately. A complete, valid handoff proceeds to the receiving owner. Missing information goes back to the responsible source. An unavailable connection enters a controlled retry or review path. A suspected duplicate is held for comparison. Each outcome records a status and next owner.

Choose the smallest useful connection

A manufacturer does not need to replace its ERP, CRM and estimating tools to improve a single handoff. Start by identifying which application already holds the needed fact and whether a supported interface can expose it appropriately.

For example, Microsoft’s Business Central reporting guide describes product-specific API and web-service options. It illustrates why the actual ERP edition and supported access matter; another system may require a different arrangement. Reporting access should not be assumed to permit writing transactions back.

Sometimes the missing connection is procedural: nobody owns a field, two teams use different identifiers or an approval rule is unclear. Software can enforce a definition once it exists. It cannot settle the commercial decision on its own.

List the assumptions behind a proposed integration. Confirm permissions, refresh needs, error handling and the support owner. If one dependency is unavailable, make that visible before the rest of the workflow starts relying on it.

Protect information at the boundary

Keep public exploration separate from access to real operational systems. Our showcases use fictional records. They do not ask a visitor to connect an ERP or upload customer data to demonstrate an interaction.

A real implementation needs its own access design. Public browser code must not contain private credentials, confidential margin rules or privileged integration logic. Serverless hosting does not remove those concerns. A static page and an authenticated business integration have different boundaries.

The same care applies to backups and supporting documents. NIST’s OT Backup Quick Start Guide emphasizes regular creation, testing and recovery exercises in operational environments. A process depends on records remaining usable, not simply on a copy existing somewhere.

Those sources support particular technical considerations. They do not certify this fictional workflow or establish that a customer implementation meets a security standard. Agree the required controls with the organization responsible for the information.

Measure a real baseline

Before automating, observe representative transactions. Record time spent entering or reconciling information separately from time spent waiting for an answer. A workflow may save a little entry effort while still leaving its largest delay untouched.

Track measures with clear boundaries: requests awaiting assignment, quotes awaiting a specific approval, order lines missing a confirmed revision or dispatched items waiting for billing information. Keep the denominator and observation period when reporting a percentage.

Treat small samples as evidence for investigation, not a guaranteed annual saving. Avoid multiplying a guessed “minutes saved” by every transaction and presenting it as a business result. Check the post-change process with the people who use it and account for the time needed to maintain the improvement.

When a measure improves, investigate whether the underlying work improved too. Closing an exception by changing its status is different from resolving the missing information.

Build the improvement in reviewable stages

Start with a map and representative examples. Agree the boundaries, pick one handoff and define what a successful change would look like. Then test the normal path and the exceptions before broadening the scope.

For RFQ-1042, a first release might link the intake record to the quote worksheet. A later release could preserve the accepted quote revision during order entry. Operational reporting might follow after those relationships are reliable.

Each stage should leave something maintainable: an agreed field definition, a tested mapping, a useful exception view or a documented recovery procedure. Record who owns it when the implementation work ends.

Figure 4 — Expand after validation. Understand the record and owner; pilot a bounded improvement; reconcile normal and exception cases; then decide whether to extend it. Validation can send the work back to the pilot rather than force an automatic rollout.

Choose the next conversation

Ask each team where they wait, repeat an entry or reconstruct a fact from another system. Pick one recurring problem that crosses a handoff and follow an actual example internally. Describe its shape without sending confidential records in an initial inquiry.

You might discover that the next step is an Access repair, an ERP exception report, a product configurator or a clearer approval process. The right starting point is the one with an understood problem, an accountable owner and a result people can verify.

Tell us where the work gets stuck. We can look at the process, the tools you already have and the connection that would make the next step easier.