## TL;DR
JPY has no minor unit, so any process that rounds JPY amounts to two decimals and back invents differences of a few yen. Check where the invoice amount, the PO amount, and the payment amount each got rounded: an interface storing JPY in a two-decimal field, or a conversion through USD at the wrong step. Align all three to whole yen and set the currency's decimal places correctly so the match compares whole numbers.

```text
JPY invoice with no decimals: "rounding difference" error breaks the invoice-to-payment match
```

## Use this when
- The match difference on a JPY invoice is a small number of yen.
- One system shows JPY amounts with decimals while another shows whole yen.
- The same vendor's invoices in other currencies match cleanly.

## Not for this skill when
- The difference is thousands of yen. That is a price or quantity issue, not decimal rounding.
- The payment was made in another currency and converted. Then the difference is conversion, handled in the FX workflow.

## Steps
1. List the JPY amount for the invoice as issued, as stored in the ERP, as on the PO, and as paid. Verify: you can see which copy carries decimals or a rounded value
2. Find the rounding point: currency decimal settings, an interface mapping, or a manual conversion in a spreadsheet. Verify: the step that creates the few-yen difference is identified
3. Correct the currency configuration so JPY is zero decimals in entry, storage, and matching. Verify: a test JPY amount stores and displays as whole yen everywhere
4. Adjust the affected invoice or payment record by the few-yen rounding difference to the rounding account, per policy. Verify: the invoice and payment now match exactly in whole yen
5. Rerun the match for the JPY invoice and check other open JPY invoices for the same artifact. Verify: no other JPY invoice carries a decimal-created difference

## Variant phrasings
### JPY rounding difference invoice payment match yen
The zero-decimal phrasing.
### Japanese yen no decimals ERP rounding mismatch
When fixing currency settings.

Compatibility: Zero-decimal currency handling in SAP, Oracle, NetSuite, and Dynamics currency configuration.

## Why it happens
Most systems default every currency to two decimals because most currencies have cents. Zero-decimal currencies such as JPY, KRW, and HUF break that assumption: amounts are whole, and any rounding to hundredths followed by rounding back to whole numbers can shift a value by a unit or two. Each shift is tiny, but match engines compare exactly, so a one-yen artifact blocks a million-yen payment.

## Edge cases / pitfalls
- The same artifact hits zero-decimal currencies in tax calculation, where per-line rounding is aggressive. Check tax lines if the header now matches but the total does not.
- Three-decimal currencies such as KWD and BHD have the mirror problem when systems truncate them to two decimals.
- Bank files for JPY are whole-yen; an ERP import expecting decimals can scale amounts by 100. A hundredfold difference is this same configuration family, not a pricing error.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PjH9BbDelBaJLm5t_WU5bg