MonetaryAmount Schema for AI Citations

TL;DR

Use MonetaryAmount whenever you publish a money figure that is not the price of an Offer — salaries, credit limits, grants, fees, balances. Always set currency with an ISO 4217 code (USD, EUR, GBP) and exactly one of value (single number) or minValue + maxValue (range). When the figure has a time pay-period (a salary), wrap the value in a QuantitativeValue with unitText set to HOUR, DAY, WEEK, MONTH, or YEAR per Google's JobPosting requirements (Google Search Central, JobPosting). For Offer prices, use PriceSpecification or price/priceCurrency directly — schema.org explicitly recommends PriceSpecification over MonetaryAmount for that case (schema.org/MonetaryAmount, schema.org/PriceSpecification).

What MonetaryAmount is for

MonetaryAmount sits on the schema.org type tree as Thing > Intangible > StructuredValue > MonetaryAmount (schema.org/MonetaryAmount). It models an amount of money that exists outside a transactional offer — examples in the official definition include $50 USD, a bank balance suitable for £1,000-£1,000,000 GBP, and a salary value.

The distinction that matters for AI grounding: schema.org's own guidance recommends PriceSpecification (and its subclasses UnitPriceSpecification, CompoundPriceSpecification) for the price of an Offer or Invoice. MonetaryAmount is the right type when the figure is a standalone claim about how much money something is worth, costs, or contains — not the price you are charging right now.

AI engines treat the type signal as part of attribution. A salary published via MonetaryAmount on JobPosting.baseSalary is far easier to cite as "the employer's stated salary" than the same number printed as plain text. Engines that summarise pay ranges or grant amounts in answers prefer sources where the type, currency, and validity period are unambiguous.

Properties — required, recommended, and time-bound

The MonetaryAmount type defines six properties beyond those inherited from Thing (schema.org/MonetaryAmount):

Three practical rules apply across consumers:

1. Always set currency with an ISO 4217 code. AI engines normalise currency before comparing or summarising, and a missing or non-standard code degrades the signal.
2. Use either value or the minValue/maxValue pair, not both. Mixing them creates ambiguity and breaks Google's Rich Results Test on JobPosting.
3. Set validFrom/validThrough for time-sensitive amounts. Grant funding windows, promotional credit limits, and seasonal salaries all benefit from explicit validity.

The JobPosting.baseSalary pattern

Google's JobPosting documentation is the most rigorous downstream consumer of MonetaryAmount. JobPosting.baseSalary accepts MonetaryAmount, Number, or PriceSpecification, but the only pattern that earns Job Search rich results is MonetaryAmount with a nested QuantitativeValue (Google Search Central, JobPosting).

Single hourly rate:

{
  "@context": "https://schema.org",
  "@type": "JobPosting",
  "title": "Software Engineer",
  "baseSalary": {
    "@type": "MonetaryAmount",
    "currency": "USD",
    "value": {
      "@type": "QuantitativeValue",
      "value": 40.00,
      "unitText": "HOUR"
    }
  }
}

Salary range:

{
  "@context": "https://schema.org",
  "@type": "JobPosting",
  "title": "Senior Data Engineer",
  "baseSalary": {
    "@type": "MonetaryAmount",
    "currency": "USD",
    "value": {
      "@type": "QuantitativeValue",
      "minValue": 130000,
      "maxValue": 165000,
      "unitText": "YEAR"
    }
  }
}

unitText is case-sensitive. Use one of HOUR, DAY, WEEK, MONTH, or YEAR exactly. Lowercase variants and friendly strings (per hour, annual) silently fail validation.

MonetaryGrant.amount pattern

MonetaryGrant uses amount (not value) and accepts either MonetaryAmount or a plain Number (schema.org/MonetaryGrant). The MonetaryAmount form is preferred because it carries currency:

{
  "@context": "https://schema.org",
  "@type": "MonetaryGrant",
  "name": "Open Knowledge Fellowship 2026",
  "identifier": "OKF-2026-014",
  "funder": {
    "@type": "Organization",
    "name": "Open Knowledge Foundation"
  },
  "amount": {
    "@type": "MonetaryAmount",
    "currency": "USD",
    "value": 75000,
    "validFrom": "2026-06-01",
    "validThrough": "2027-05-31"
  }
}

For recurring grants or tranches, repeat MonetaryGrant with distinct validFrom/validThrough windows rather than collapsing them into one MonetaryAmount range — the validity fields apply to the whole MonetaryAmount, not to individual disbursements.

Returns and shipping fees pattern

Google Merchant Center accepts MonetaryAmount on returnShippingFeesAmount and on the shippingRate of ShippingService (Google Merchant Center help, Google Search Central, shipping policy). The simplest valid form:

{
  "@context": "https://schema.org",
  "@type": "MerchantReturnPolicy",
  "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
  "merchantReturnDays": 30,
  "returnFees": "https://schema.org/ReturnShippingFees",
  "returnShippingFeesAmount": {
    "@type": "MonetaryAmount",
    "currency": "USD",
    "value": 4.99
  }
}

Do not put a Product price into MonetaryAmount on Offer. Use price + priceCurrency on the Offer directly, or PriceSpecification for unit pricing — that is what Google Merchant Center's product feed expects.

When to use PriceSpecification instead

The schema.org MonetaryAmount and PriceSpecification pages both contain explicit cross-references: PriceSpecification is for the price of an Offer or Invoice; MonetaryAmount is for independent amounts such as salaries and credit limits (schema.org/PriceSpecification). The decision tree:

Validator quirks to know

• Google's Rich Results Test rejects bare numbers in JobPosting.baseSalary. Even though schema.org accepts Number, Google requires the MonetaryAmount + QuantitativeValue + unitText form for Job Search rich results.
• Mixing value with minValue/maxValue triggers a Critical error in most validators. Pick one pattern.
• Lowercase unitText is silently treated as missing. The case-sensitive enumeration is documented on Google's JobPosting reference.
• Currency normalisation differs. Google AI Overviews and Perplexity will display the ISO 4217 code as-is; ChatGPT search may format it as a symbol. Always store the ISO 4217 form in your markup; let consumers handle display.
• validFrom/validThrough must be ISO 8601. Localised date strings (May 1, 2026) are not parsed.

Common mistakes

• Putting an Offer price inside MonetaryAmount on Offer.priceSpecification instead of using PriceSpecification or price/priceCurrency. Some practitioners do this; it works in some validators and not others, and it muddies AI extraction. Follow schema.org's own guidance.
• Omitting currency when the figure is in USD because "the page is in English". Currency is independent of language.
• Using a custom enumeration for unitText (PER_HOUR, monthly). Stick to Google's case-sensitive list.
• Treating validThrough as exclusive when it is inclusive — the date itself is still valid.
• Marking up a MonetaryAmount on a page that does not display the value to humans. AI engines penalise cloaked structured data; the markup should match what the user sees.

FAQ

Q: Is MonetaryAmount required for JobPosting.baseSalary?

Not by schema.org, which accepts MonetaryAmount, Number, or PriceSpecification. It is effectively required by Google's Job Search rich results, which need MonetaryAmount + QuantitativeValue + unitText to render the salary in the rich card (Google Search Central, JobPosting).

Q: Can I use MonetaryAmount for the price of a product?

You can, but schema.org explicitly recommends against it. Use price + priceCurrency on the Offer, or PriceSpecification (or its subclasses) on Offer.priceSpecification. MonetaryAmount is reserved for independent amounts such as salaries and credit limits (schema.org/MonetaryAmount).

Q: How do I mark up a salary range with one of the bounds open?

Use the bound you have and omit the other — for example minValue: 130000 with no maxValue. AI engines will surface this as "from $130,000" rather than as a range. Avoid sentinel values like 9999999; they leak into citations.

Q: Should I include validFrom and validThrough for a permanent salary?

No. Permanent or open-ended amounts should omit both. Use the validity fields only for time-bound figures such as promotional credit limits, grant tranches, or seasonal pay rates.

Q: What currency code should I use for cryptocurrencies?

The ticker symbol (BTC, ETH, SOL) per the schema.org currency documentation, which explicitly accepts cryptocurrency tickers (schema.org/currency). Do not invent a fake ISO 4217 code such as XBT-USD.

Q: Do AI engines actually read MonetaryAmount or just the visible number?

Both. The visible number is the user-facing claim, and the markup is the structured signal that lets the engine attribute and convert it correctly. Pages that publish a salary in plain text alone are still citable, but pages that pair the plain text with a MonetaryAmount block are easier for an engine to summarise without ambiguity. Always keep the markup consistent with the visible value.