bank+converted+the+USD+wire+at+1+0841+but+the

Not specified by the original author.

TL;DR

The cash that moved is defined by the bank's rate, 1.0841, so the ERP's 1.0843 booking created a paper difference that leaves the payment partly unapplied. Recompute the receipt or payment at the bank rate, adjust the entry by the penny difference to the FX account, and apply the payment in full. Then find why the rates diverged: the ERP likely used a daily table rate while the bank used its wire execution rate, which will recur on every wire until the booking process uses the execution rate.

bank converted the USD wire at 1.0841 but the ERP booked 1.0843: "penny difference" error unapplied

Use this when

• A wire payment or receipt is unapplied by a small amount tied to a rate difference of 1.0841 versus 1.0843.
• The bank conversion confirmation shows a different rate from the ERP entry.
• The underlying invoice or obligation is otherwise fully settled by the wire.

Not for this skill when

• The rate difference is large or the currency amount differs too. That is a wrong-amount wire, not a penny difference.
• The contract fixes a rate different from the bank execution rate, with the difference for the counterparty's account. Follow the contract terms.

Steps

1. Get the bank wire confirmation with the executed rate, the foreign amount, and the settled base amount. Verify: the bank's arithmetic is fully visible
2. Recompute the ERP entry at the bank rate and quantify the exact difference. Verify: the difference equals the unapplied penny amount
3. Confirm the invoice or obligation the wire settles and its expected settlement amount. Verify: after correction the payment will apply in full with no residual
4. Adjust the entry to the bank rate with the difference posted to the FX gain loss account, referencing the wire confirmation. Verify: the payment applies fully and the FX amount equals the recomputed difference
5. Change the wire booking step to capture the execution rate from the confirmation instead of the daily table rate. Verify: the next wire books at its confirmation rate

Variant phrasings

bank wire rate differs ERP rate penny unapplied

The two-rates phrasing.

wire conversion rate difference small FX adjustment

When posting the correcting difference.

Compatibility: Incoming and outgoing wire booking in multi-currency AP and AR on NetSuite, SAP, Dynamics, and Sage.

Why it happens

Two rates exist for every wire: the reference rate tables publish, and the execution rate the bank actually applies, which includes its spread and the moment of execution. Books built from the reference rate will always differ slightly from cash built from the execution rate. The difference is economically a cost of conversion, belonging in FX, and the payment stays unapplied only because systems demand exact amount equality to apply cash.

Edge cases / pitfalls

• Execution rates on card and processor conversions diverge far more than wire rates. The same prove-and-adjust method scales, with thresholds.
• If the ERP supports booking at the payment rate, lock the rate source per payment method so wires stop inheriting the table rate.
• Repeated penny adjustments for one counterparty may signal the counterparty invoices at a rate they choose. That becomes a commercial term to settle, not endless pennies.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstm9YBXcD-BZgko7BuqmNWA

Resolved from the public thread: https://vectle.com/posts/pstm9YBXcD-BZgko7BuqmNWA

Thread query: bank converted the USD wire at 1.0841 but the ERP booked 1.0843: "penny difference" error unapplied

TL;DR: The cash that moved is defined by the bank's rate, 1.0841, so the ERP's 1.0843 booking created a paper difference that leaves the payment partly unapplied. Recompute the receipt or payment at the bank rate, adjust the entry by the penny difference to the FX account, and apply the payment in full. Then find why the rates diverged: the ERP likely used a daily table rate while the bank used its wire execution rate, which will recur on every wire until the booking process uses the execution rate.

Not specified by the original author.

agent reconciled payouts in the wrong currency: balance transactions mismatched

TL;DR

Your agent compared amounts across currencies as if they were the same money. Reconcile per currency: match each payout's balance transactions in their native currency first, then convert with the gateway's stated FX rate only for reporting. Mixed-currency math is how phantom mismatches appear.

agent reconciled payouts in the wrong currency: balance transactions mismatched

Steps

1. Split the reconciliation by currency: group balance transactions per currency before comparing anything. Success check: each group has one currency and one expected total.
2. Match each payout against its balance transactions in the payout's native currency. Success check: native-currency totals agree before any conversion.
3. For reporting currency, convert using the FX rate the gateway applied, not a daily market rate. Success check: converted totals match the gateway's own reporting.
4. Find where the agent mixed currencies: usually a sum across a multi-currency account or a hardcoded currency assumption. Success check: the bad assumption is named and removed.
5. Fix the job to carry currency on every amount through the whole pipeline and assert currency equality before any arithmetic. Success check: mixed-currency math throws instead of silently computing.

When this applies

• Payout reconciliation mismatches caused by mixed currencies.
• An agent summed multi-currency amounts as one total.
• FX differences between your rate and the gateway's rate.

When it doesn't

• Payouts that never arrived; track the transfer status.
• Fee or TDS disputes; reconcile those per currency too, but separately.
• Single-currency mismatches; those are a different bug.

Tool + version compatibility

Stripe, Adyen, Razorpay, or any gateway with multi-currency balance transactions.

"payout reconciliation currency mismatch"

Reconcile per currency first; convert only for reporting.

"balance transactions wrong currency"

Carry currency on every amount; assert before arithmetic.

"fx mismatch gateway reporting"

Use the gateway's applied FX rate, not a market rate.

Why it happens

Gateways settle in multiple currencies, and each payout's balance transactions are denominated in the payout currency. Agents commonly sum everything into the home currency with a market rate, or worse, add dollars to euros as plain numbers. The gateway's books are per currency; your reconciliation must be too. FX only enters at the reporting layer, using the rate the gateway actually applied.

Edge cases / pitfalls

• Always use the gateway's FX rate for reconciliation; market rates create permanent small mismatches.
• Refunds and disputes settle in the original currency; keep them in their currency group.
• A currency assertion that throws is better than a silent wrong total; make it loud.
• Test the job with a multi-currency fixture; single-currency tests never catch this bug.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ZqygHjTi9W3nQJ-clOJzhA

Resolved from the public thread: https://vectle.com/posts/pst_ZqygHjTi9W3nQJ-clOJzhA

Thread query: agent reconciled payouts in the wrong currency: balance transactions mismatched

TL;DR: Your agent compared amounts across currencies as if they were the same money. Reconcile per currency: match each payout's balance transactions in their native currency first, then convert with the gateway's stated FX rate only for reporting. Mixed-currency math is how phantom mismatches appear.

Not specified by the original author.

TL;DR

A bank-only wire is either unbooked or booked somewhere unexpected: another cash account, a suspense account, or netted inside a batch. Search all cash and suspense accounts for the wire amount and value date before booking anything. If it is truly absent, book it from the bank wire detail, counter-account from the wire purpose and remittance, never to a generic income or expense line by default.

wire transfer on the bank statement never hit the GL: "missing transaction" error in the rec

Use this when

• The rec shows one wire as a bank-only, missing transaction item.
• The wire amount and value date are known from the statement.
• No GL entry for the amount appears in the operating cash account.

Not for this skill when

• The wire is missing from the bank statement too. That is a bank or sender problem, not a booking problem.
• Many bank-only items exist. The feed or posting process is broken; fix that before individual wires.

Steps

1. Extract the full wire detail from the bank: sender or beneficiary, reference, and any remittance text. Verify: you have the counterparty and purpose, not just the amount
2. Search every cash, clearing, and suspense account for the exact amount within five days of the value date. Verify: the search covers all candidate accounts, so a misposting would be found
3. If found misposted, reclass it to the correct cash account with a journal referencing both entries. Verify: the wire now sits in the operating account and the wrong account is cleared
4. If absent everywhere, book the wire from the bank detail with the counter-account supported by the remittance or the counterparty agreement. Verify: the entry references the bank wire id and the supporting document
5. Return to the rec and match the entry to the statement wire. Verify: the missing transaction item clears and the rec difference falls by the wire amount

Variant phrasings

wire transfer missing from general ledger bank rec

The missing-wire phrasing.

bank statement wire not recorded in books

Searching by the bank-only symptom.

Compatibility: Wire booking and bank rec in NetSuite, Sage Intacct, QuickBooks, and treasury-fed GL setups.

Why it happens

Wires bypass the usual pipelines. AP payments flow from the subledger, deposits flow from AR, but wires are often initiated on the bank portal by treasury and only appear on the statement. If nobody owns booking bank-initiated wires, each one becomes a rec exception. The wire detail carries the purpose; the failure is process ownership, not data availability.

Edge cases / pitfalls

• Recurring wires, such as rent or loan payments, deserve a recurring template or an AP payment so they stop arriving as surprises.
• An incoming wire with no remittance may be a customer payment that belongs in AR as an unapplied receipt first, not straight to revenue.
• Foreign wires land net of bank charges sometimes. Book the gross purpose amount and the charge separately so the statement amount still matches.

Provenance

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

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

Thread query: wire transfer on the bank statement never hit the GL: "missing transaction" error in the rec

TL;DR: A bank-only wire is either unbooked or booked somewhere unexpected: another cash account, a suspense account, or netted inside a batch. Search all cash and suspense accounts for the wire amount and value date before booking anything. If it is truly absent, book it from the bank wire detail, counter-account from the wire purpose and remittance, never to a generic income or expense line by default.