> 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-split-payments-by-linking-an-entry-when-1-1-becomes-many-to-1.md). # Resolving Split Payments by Linking an Entry (When 1:1 Becomes Many-to-1) *Time needed: \~15 minutes · Works on the Exceptions screen* A 1:1 rule expects one entry on each side: one order in the OMS, one payment at the PSP. But real life sometimes produces **two entries on the left for one entry on the right** — most commonly a **split payment**: the customer pays one order in two parts (two cards, gift card + card, two installments), so your OMS records two rows, while the PSP settles it as a single payment. The rule can't match this on its own — it was told to expect one-to-one. The fix is a one-time manual action: **link the extra entry to the existing transaction**, turning that one transaction into a many-to-1 match. {% embed url="" %} ### The example For Aug 25, our OMS file has **two rows for order ORD-10540007** — the customer paid 75.00 and then 45.00. PSP 1's report has **one row** for the same order: a single payment of 120.00. | System | Order | Rows | Amounts | | ------ | ------------ | ---- | ------------- | | OMS | ORD-10540007 | 2 | 75.00 + 45.00 | | PSP 1 | ORD-10540007 | 1 | 120.00 | The money is all there — 75 + 45 = 120. The system just needs to be told these three entries belong together. ### What you'll see after uploading Upload both files as usual (Guide 2). The other nine orders in the file match cleanly — **Matched (Auto)**. Order ORD-10540007 splits into two problems: 1. **A transaction that doesn't add up.** One OMS entry was paired with the PSP entry, but the amounts disagree (75.00 vs 120.00) — so on the **OMS ↔ PSP 1** tab it shows as an exception instead of a match. 2. **A leftover entry.** The second OMS row (45.00) couldn't join — the rule had already used its one expected entry for this order. It lands in **Exceptions** as an entry **needing manual review**. Neither is an error in your data. It's the 1:1 rule correctly saying: *"I found more entries than I was told to expect — a human should confirm they belong together."* ### How to resolve it: link the entry 1. **Go to Operate → Exceptions** and open the **OMS ↔ PSP 1** tab. 2. **Find the transaction** — search for the order ID (ORD-10540007). Open it. You'll see the OMS side (75.00) vs the PSP side (120.00), short by exactly the amount of the leftover entry. 3. **Click Resolve Exception** and choose **Link a transformed entry**. 4. **Pick the waiting entry.** You'll see linkable entries — the OMS entries for this order that aren't part of any transaction yet. Our 45.00 entry is right there. Select it. 5. **Confirm, with a remark** — e.g. *"Split payment: customer paid 75 + 45 for one order."* The transaction now has **two OMS entries against one PSP entry** — 75 + 45 = 120 — the amounts agree, and it resolves to matched. The leftover-entry exception disappears too, because that entry now belongs to a transaction. ### Check your work Open the transaction again (or find it on the Transactions screen, Guide 4): * Both OMS entries and the PSP entry appear together, grouped by account. * The status shows it was resolved manually. * The **audit trail** records the link — who did it, when, and your remark — so the "why" survives long after you've forgotten this order existed. ### When to link vs. when *not* to **Link when the money genuinely adds up** — the extra entries are parts of the same real payment (splits, installments) and their sum equals the other side. **Don't link to force numbers together.** If the second entry exists because of a duplicate row in the file or a system error, linking would hide a real problem. Check the entry's lineage first (Guide 3) — if it traces to a duplicated or wrong file, void it instead. > 💡 **Happens on every order?** If split payments are routine for your business (installments, BNPL), don't hand-link them daily — tell the Hyperswitch team. The rule can be changed from one-to-one to many-to-one so these match automatically, like your PSP ↔ Bank rule already does. ### Quick checklist * ✅ I found both halves of the problem: the mismatched transaction and the leftover entry. * ✅ I confirmed the amounts add up before linking (75 + 45 = 120). * ✅ I linked the entry with a remark explaining the split. * ✅ The transaction now shows all three entries and a matched status. --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.hyperswitch.io/other-features/payments-modules/reconciliation-product/reconciliation-user-guides/exceptions/resolving-split-payments-by-linking-an-entry-when-1-1-becomes-many-to-1.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.