> ## Documentation Index
> Fetch the complete documentation index at: https://docs.retailgrid.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Review and approve competitor matches

> Approve, reject, reopen, or rematch competitor matches one at a time or in bulk, and let in-policy matches auto-approve.

The [Competitor matching](https://docs.retailgrid.io/price-monitoring/competitor-matching.md) page tells you how good a scan is. The **Review matches** workspace is where you act on it - confirming the matches you trust, fixing the ones you don't, and clearing the queue so only clean matches feed your pricing.

Use it after validating a scan, whenever the queue holds matches waiting on a decision.

## When to use it vs. the validation tabs

The coverage, match-quality, blind-spots and price-sanity tabs are read-only summaries of the latest delivery. They tell you whether the scan is worth trusting. The Review matches workspace is the opposite: every decision you make here **persists** and changes the matched data your pricing reads. Reach for it when you need to correct or confirm individual matches, not just judge the scan as a whole.

## The review queue

Each row pairs one of your products with a competitor listing, so you can judge the match by eye: your product and the competitor's own listing title side by side, the confidence, the match type (direct or substitute), the method that produced it, both prices, and the gap between them. Filter and sort the queue the way you would any grid - by confidence, competitor, category, or price gap - to work the riskiest matches first.

## Act on a match

For any match you can:

* **Approve** - confirm the match. Its competitor price is trusted for pricing.
* **Reject** - discard the match. The competitor price stops feeding your pricing for that SKU.
* **Reopen** - send a previously decided match back to the queue when you want to look again.
* **Rematch** - replace the competitor listing with a better one. Pick the replacement listing and mark whether it's a **direct** match or a **substitute**. A rematch always needs a replacement - that's the whole point of the action.

You can leave a note on any decision, so why you rejected or rematched a row is there when someone looks later.

## Approve in bulk

Once a filtered set looks right, **approve everything in the current filters** in one action instead of clicking each row. A preview shows how many matches the bulk approval will cover before you commit, so you only approve the set you actually reviewed. The common pattern: filter to high-confidence direct matches, bulk-approve them, then work the uncertain rows by hand.

## Auto-approve in-policy matches

To keep the queue from filling up with matches that never need a human, an organization admin can turn on **auto-approval** in the match review settings. Matches that clear the confidence and match-type policy are approved automatically; everything else still waits for review. Only organization admins can change this setting, because it affects every future scan.

## How decisions flow through

Every review action schedules a reconciliation that folds your decision back into the matched data behind the scan. Approved and auto-approved matches become part of the competitor prices your CPI metrics and Price Match rules read; rejected ones drop out. You don't publish anything separately - deciding a match is the publish.

## Related

* [Competitor matching](https://docs.retailgrid.io/price-monitoring/competitor-matching.md) - validate a scan before you review it
* [Price Monitoring](https://docs.retailgrid.io/agents/price-monitoring.md) - discover competitor prices with AI search
* [Competitor prices data spec](https://docs.retailgrid.io/data-requirements/competitors.md)
* [Competitive Position dashboard](https://docs.retailgrid.io/dashboards/competitive-position.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.