> For the complete documentation index, see [llms.txt](https://docs.hyperswitch.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hyperswitch.io/other-features/payments-modules/reconciliation-product/reconciliation-user-guides/exceptions/resolving-data-mismatches-when-amounts-agree.md).

# Resolving Data Mismatches When Amounts Agree

*Time needed: \~10 minutes · Works on the Exceptions screen*

Both systems show **100.00**, but the transaction still says **Data Mismatch**. Why?

Your matching rule checks more than money. In this setup, it links the OMS **Order Id** to the PSP 1 **Merchant Reference**, then validates the reference, **Status**, **Amount**, and **Currency**. A difference in status can keep the transaction from matching even when the amounts agree.

<figure><img src="https://1943537505-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fkf7BGdsPkCw9nalhAIlE%2Fuploads%2F43Wxzb3jekmrLp5jq11Z%2FScreenshot%202026-09-20%20at%201.43.58%E2%80%AFPM.png?alt=media&amp;token=7715dadf-b280-4627-a826-9570d82be341" alt=""><figcaption></figcaption></figure>

***

#### The example

Your rule links the OMS and PSP 1 entries for **ORD-10540011** using **Order Id → Merchant Reference**. Both sides show **100.00** in the same currency. In this example, the OMS status is **`success`**, so the PSP 1 status is expected to be **`success`** too — but the PSP entry contains **`charged`**.

| Compared value                | OMS           | PSP 1         |
| ----------------------------- | ------------- | ------------- |
| Order Id → Merchant Reference | ORD-10540011  | ORD-10540011  |
| Amount                        | 100.00        | 100.00        |
| Currency                      | Same currency | Same currency |
| Status                        | `success`     | `charged`     |

The status comparison fails: **expected `success`, actual `charged`**. The matching reference identifies the same payment, but the rule still requires the status values to agree.

Here, **Status** is a field from the source data. It is separate from the reconciliation result **Data Mismatch** shown on the transaction.

#### Step 1: Open the mismatch details

Go to **Exceptions → Recon**, and open the transaction showing **Data Mismatch**.

Read the **expected value versus actual value** for each mismatched field. For this example, look for the status difference: **`success` expected, `charged` received**. Then inspect the entries grouped by account.

Confirm that:

* The entries represent the same real payment.
* The amounts, currency, and credit/debit directions make sense together.
* You have checked every reported field difference, not just the first one.

> 💡 A matching amount does not establish that two entries belong together. Check the payment references and source records before accepting a difference.

#### Step 2: Decide what the difference means

| What you find                                                             | Appropriate next step                                                            |
| ------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| Both values are accurate and describe the same thing in different systems | Consider Force Match for this explained, eligible mismatch.                      |
| The values describe genuinely different payments or business events       | Keep the exception open while you investigate the pairing and source data.       |
| The same difference appears repeatedly                                    | Ask the Hyperswitch team to review the transformation or matching configuration. |

For this example, check the original PSP record and your configured status mapping. If the verified value should be **`success`** but the entry contains **`charged`**, correct the entry. If the PSP genuinely uses **`charged`** to mean a successful payment, confirm that meaning with your team before accepting the difference. The two labels are not automatically interchangeable.

#### Step 3: Resolve a verified data error

If the PSP entry should contain **`success`**, choose **Edit Entry** and change its status field from **`charged`** to **`success`**, using the original file, source-system record, or verified mapping as evidence. Keep the verified amount, currency, and reference unchanged, and review the resulting transaction entries before confirming.

Add a specific remark, such as:

*"Corrected PSP status from charged to success for ORD-10540011 after verifying the source record and expected status mapping. Amount 100.00, currency, and merchant reference verified."*

After saving, inspect the resulting status and entries. Both source-data status fields should now show **`success`**. If this was the only issue and the transaction is fully resolved, check that it shows **Matched (Manual)**.

#### A note on transformation configuration

If your PSP reports a successful payment as **`charged`**, the normal setup should handle this in the **transformation configuration**: ask hyperswitch team to map the incoming value **`charged`** to **`success`** and store **`success`** in the transformed entry's status field.

That way, reconciliation compares **`success`** on the OMS side with **`success`** on the PSP side, so matching continues automatically when the other checks agree.

**This guide is for the rare scenario where a status mismatch still reaches Exceptions and needs a one-off manual resolution.** Routine differences in how your systems name a successful payment should be handled during transformation.

If you encounter this mismatch repeatedly, share an example with the Hyperswitch team so they can add or correct the mapping in your transformation configuration. Resolve existing exceptions separately; updating the mapping does not automatically close earlier mismatches.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.hyperswitch.io/other-features/payments-modules/reconciliation-product/reconciliation-user-guides/exceptions/resolving-data-mismatches-when-amounts-agree.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.