Separate HTTP language from the buying question
IETF RFC 9110 section 9.2.2 defines idempotent HTTP methods. It does not establish that a quoted workflow, database action, provider integration, or client message has safe duplicate behavior. Ask the provider to describe the specific intended action and the evidence that shows its proposed boundary.
Use one worksheet for every proposal
Complete the accompanying retry and duplicate-action quote worksheet from the written proposal or a dated vendor response. Do not compare proposals until each one has the same rows filled in:
- one intended action and the record that identifies it;
- the treatment of an unknown first outcome and a retry;
- the declared result for a repeat and for the same identity with different material input;
- the person who reconciles unresolved records and informs staff or clients;
- acceptance evidence, incident support, and termination handoff.
Leave a row blank when the proposal does not say. A blank is an evaluation result, not permission to assume that an important behavior is included.
Normalize the commercial basis before comparing
First complete the worksheet's quote-level commercial-basis table: currency; one-time cost; recurring amount and billing period; usage unit, tier, volume per billing period, and price; change-work assumption; taxes and pass-throughs; and a buyer-chosen horizon. Then calculate each proposal over the same period; do not compare a one-time amount from one proposal with a monthly amount from another.
normalized total = one-time + recurring over horizon + usage per billing period over horizon + change work + included taxes/fees
Keep unknown and excluded costs outside the total and beside it. A visible incomplete total is more useful than one that silently treats an omitted fee as zero.
The worksheet does not supply a rate, volume, tax treatment, or total. It makes buyer inputs reproducible and exposes where a quote does not establish them.
Stop when the proposal hides the recovery work
Pause comparison if the provider cannot identify the action, outcome record, retry boundary, duplicate or mismatched-input treatment, reconciliation owner, acceptance evidence, support route, or termination handoff. The buyer may choose to narrow the automation to a reversible internal action, retain a manual review step, or request a scoped proof before committing.
For proposal assumptions, see Record Software Proposal Assumptions Before Comparing Quotes. For a scheduling exception, see Review a Cross-Time-Zone Rescheduling Quote. For a paired-record exception, see Review a Payment-Confirmation Exception Quote.
Does this worksheet say a proposal is fair, safe, or legally sufficient?
No. It exposes scope, exclusions, and evidence requests. Pricing, contract, security, policy, and legal decisions require the buyer's accountable advisers and the actual written terms.