International Payments Reconciliation — match dLocal captures to our books

Every foreign-card payment routed through dLocal generates two records: one on our side (the Invoice / Receipt + PaymentIntent) and one on dLocal's side (their settlement report). At month-end, your accountant needs to prove these match. This report is the workbench for that.

Before you start

• You must have Account Master permission.
• You need a dLocal sub-merchant account already set up and Approved (see Setup → International Payments).
• You'll want a copy of dLocal's own settlement report open in another tab (their Merchant Dashboard → Settlements section). This page is what you cross-check against.

Steps

1. Go to Reports → International Payments Reconciliation.

2. Pick a window (last 1 / 3 / 6 / 12 / 24 months). Most accountants close monthly, so 1 month is the default working view.

3. The summary card at the top shows the totals for the window:

   • Transactions — count of dLocal intents (with how many confirmed)
   • Total charged — what the guests authorised
   • Booked (hotel rate) — the sum of invoice amounts (what we booked revenue for)
   • Processing fee — the surcharge line, always the pass-through
   • Acquirer took — what dLocal kept in fees + interchange

4. The row-per-transaction table shows each intent with columns:

   • When — the intent's created date
   • Doc — Invoice number or Receipt number the intent settled into
   • Country — the guest card's issuer country (US, GB, DE, etc.)
   • Reference — dLocal's payment ID
   • Base — our invoice amount
   • Fee — the international-processing fee we passed on
   • Charged — what the guest authorised (Base + Fee)
   • Acquirer — dLocal's take (their fee + interchange)
   • Hotel net — what actually settled to your dLocal sub-merchant
   • Refund — any refunds against this intent
   • Status — Confirmed / Pending / Failed / Cancelled

5. Cross-check the summary card against dLocal's dashboard:

   • Our Total charged ≈ dLocal's "Total Payments" for the same window (rounding drift up to a few Naira is normal).
   • Our Acquirer took ≈ dLocal's "Total Fees" for the window.
   • Our Hotel net ≈ dLocal's "Total Net Payout" for the window.
   • If any number is off by more than ~₦100 on a full month, dig into the row-level detail — sort by amount and look for outliers.

6. Print the summary + table using the Print button (top right). It formats to A4 landscape and hides the toolbar. Attach this PDF to your accounting close file.

Tips

• Refresh re-pulls the report from live data — use after new charges land, or when you've just closed a chunk of settlements on dLocal's side.
• Country column is your fraud-lens: a spike in one issuer country outside your usual guest mix is worth flagging to the acquirer.
• Unlinked rows (Doc column shows "Unlinked") = a dLocal intent that didn't attach to an invoice / receipt. Usually means the guest opened the payment but the cashier abandoned the checkout — safe to leave, but check the balance is refunded so we're not sitting on unclaimed money.
• Refund column shows the SUM refunded on that intent, whether partial or full. If Refund equals Charged, the intent has been fully reversed.
• Currency — all amounts are in the tenant's home currency (Naira by default). dLocal presents the guest with their local currency at authorisation time; what we see is the NGN-equivalent settlement.

Common problems

• "No dLocal transactions in this window yet" — either genuinely no foreign card activity, or the intent's Provider column doesn't match "DLocal" (very rare — usually only if a legacy row was mis-tagged). Double-check by searching Payment Logs for the same window.
• Acquirer column is blank — happens for intents that were initiated but never confirmed. dLocal only returns their fee breakdown on completed captures. Confirmed → filled; Pending / Failed → blank.
• Hotel net matches Base exactly — good sign the pass-through is working. The Fee should equal Acquirer within a small margin (dLocal takes slightly more than 4% on cards, slightly less on transfers).
• Big drift between our Total Charged and dLocal's dashboard total — usually a timezone edge case. dLocal reports in UTC; we report in tenant local time. Widen the window by a day either side.
• Missing rows compared to dLocal's dashboard — the webhook may not have fired (or arrived after a delay). Payments show up in the report as soon as the intent is created; the settlement columns fill in AFTER the webhook fires. If a row is completely missing, check POST /api/webhooks/dlocal receiver logs.
• Very old rows are gone — the window maxes out at 24 months. For historical audit, keep monthly PDFs from this page in your close file.