What Is MonetaryAmount in Shipping Schema?

MonetaryAmount is a structured-data type that represents either a shipping cost or an order-value eligibility range, depending on the property where it appears.

Inside shippingRate, it can state a fixed charge or maximum charge. Inside orderValue, it defines the cart-value band that selects a ShippingConditions rule. The same type therefore has two distinct roles, and its properties must be interpreted from their parent relationship.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Read MonetaryAmount in its parent context.
• Always use a three-letter ISO currency code.
• Keep shipping cost separate from cart eligibility.

Use the free backlink checker while reviewing linked product pages.

Primary specification: Schema.org definition for MonetaryAmount.

MonetaryAmount is accurate only when its numbers and currency answer the question asked by the parent shipping property.

As shippingRate, MonetaryAmount uses value for a fixed cost or maxValue for a maximum cost, together with currency.

A flat $7.95 charge uses value 7.95 and currency USD. A variable carrier quote that will not exceed $20 may use maxValue 20 when that ceiling is defensible. Do not provide value and maxValue together in this rate context because one claims an exact cost while the other claims only an upper bound.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Identify whether the cost is fixed or capped.
2. Select value or maxValue.
3. Add the transaction currency.
4. Attach destination and eligibility conditions.
5. Compare with checkout.

A maximum should not be presented as the usual or guaranteed cost in visible copy.

Shipping-rate MonetaryAmount must state either one exact cost or one defensible ceiling, never both at once.

As orderValue, MonetaryAmount uses minValue, maxValue, or both to define which cart subtotal band qualifies for a ShippingConditions rule.

This number is not the shipping charge. For example, minValue 75 USD can select a free-shipping condition whose shippingRate has value 0 USD. A lower paid band might use minValue 0 and maxValue 74.99. The two MonetaryAmount objects perform different jobs.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Define the subtotal basis.
• Use the market currency.
• Make adjacent bands complete and non-overlapping.
• Keep orderValue separate from shippingRate.

Review ShippingConditions schema for the full rule-matching model.

Order-value MonetaryAmount selects the eligible cart band; it never states the delivery charge by itself.

Use value for an exact shipping cost, minValue and maxValue for eligibility boundaries, and maxValue alone for a shipping-cost ceiling.

The property choice follows both context and certainty. A fixed charge can use value. A cart range can use minimum and maximum together. An open-ended range can omit one boundary, but the team should understand the resulting default breadth. Do not use minValue to claim the minimum possible shipping cost in a rate context unless the consuming contract explicitly supports that meaning.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Identify the parent property.
2. Decide whether the number is exact, capped, or a boundary.
3. Select only fields with that meaning.
4. Add currency.
5. Validate sample inputs.

Using the right numeric field prevents a range from being mistaken for a price or vice versa.

Property selection is correct when the number's certainty and parent context agree.

Mark genuinely free shipping with shippingRate MonetaryAmount value 0 and the applicable currency inside the condition that qualifies for it.

Zero does not make the condition universally free. If free delivery requires a $75 order, membership, destination, or service level, those inputs must select the zero-rate condition. A product page should not advertise free shipping when the displayed item alone fails the threshold and no cart context is available.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Use numeric zero, not “Free.”
• Keep currency explicit.
• Represent thresholds and regions.
• Separate paid expedited options.

A zero amount is a cost outcome, while eligibility comes from the surrounding condition.

Free-shipping markup is truthful only when every stated condition needed to obtain the zero rate is represented.

Currency should use the three-letter ISO 4217 code for the shipping charge or order-value band, and it must match the market context evaluated by checkout.

A $75 threshold is not equivalent across USD, CAD, and AUD. Likewise, a USD shipping charge should not be attached to a CAD Offer without an explicit conversion model. Symbols are ambiguous and locale codes describe language or region, not money.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Determine the checkout market.
2. Read its transaction currency.
3. Generate threshold and rate in that currency.
4. Align visible shipping messages.
5. Test localized sessions.

See PriceCurrency in Product schema for the wider Offer context.

Currency makes MonetaryAmount interpretable and must remain consistent across thresholds, rates, Offers, and checkout.

Threshold bands should cover intended cart values exactly once, with explicit treatment of the boundary amount and decimal precision.

A paid band ending at 74.99 and a free band starting at 75.00 works for a two-decimal USD subtotal. A first band ending at 75 and a second starting at 75 creates overlap. A first band ending at 74 and a second starting at 75 leaves values between them uncovered.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Use the currency's pricing precision.
• Define inclusive boundaries.
• Test just below, at, and above thresholds.
• Account for discounts and taxes consistently.

The threshold basis should match checkout's subtotal stage, including whether coupons are applied before eligibility. Document whether taxes, gift cards, store credit, discounts, and excluded product categories affect the qualifying amount. Test each adjustment because an apparently simple threshold can move after checkout recalculates the cart.

A sound threshold partition maps every intended cart to one shipping outcome with no ambiguity.

Common mistakes include confusing order value with shipping cost, providing value and maxValue together, omitting currency, using symbols, publishing false free shipping, and creating overlapping threshold bands.

Another error is using a fixed MonetaryAmount for a complex carrier formula or publishing a maximum as though it were exact. A syntactically valid number can still conflict with checkout because destination, service, cart value, or product weight changes the result.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Identify the MonetaryAmount parent.
2. Translate the rule into plain language.
3. Recalculate representative carts.
4. Repair the policy source.
5. Verify rendered output and checkout.

Correcting the source rule prevents the same monetary error from propagating across the catalog.

MonetaryAmount errors require contextual pricing reconciliation, not only numeric-format fixes.