Payout reconciliation is the process of matching payments collected by your payment provider with the invoices in your ERP system. For most e-commerce merchants, this is one of the most time-consuming parts of bookkeeping — and one of the areas where Junipeer adds the most value.
This guide explains how payout reconciliation works end to end, what configuration it requires, what can go wrong, and how to handle the edge cases that come up in real-world use.
How payout reconciliation works
The overall flow follows five steps. Understanding this sequence makes it much easier to diagnose problems when they occur.
Step 1 — Invoices are created with references. When Junipeer syncs an order from your e-commerce platform, it creates an invoice in your ERP. Each invoice carries a unique reference number that ties it back to the original order and payment transaction. This reference is the key to everything that follows — without it, the payout cannot be matched.
Step 2 — The payment provider collects payments. Your customers pay through one or more payment providers (card processors, buy-now-pay-later services, digital wallets, etc.). The payment provider holds these funds temporarily.
Step 3 — The payment provider issues a payout. Periodically (usually daily, sometimes weekly), the payment provider bundles completed transactions into a single payout and transfers the net amount to your bank account. The payout report lists every transaction included, along with gross amounts, fees, and the net settlement amount.
Step 4 — Junipeer matches transactions to invoices. Junipeer receives the payout report — either via a webhook from the payment provider or through a scheduled fetch — and matches each transaction to its corresponding invoice in your ERP using the reference numbers from Step 1. Matched invoices are marked as paid, with the payment date and amount recorded.
Step 5 — Fees are written off. The difference between the gross transaction amount and the net payout is the payment provider's fee (processing fees, transaction costs, interchange fees, etc.). Junipeer books this difference to a designated fee account in your ERP as a write-off, so your revenue accounts stay accurate and your fee costs are tracked separately.
What you need to configure
Before payout reconciliation can work, several things must be set up in both your ERP and in Junipeer.
Payment method accounts
Each payment provider used in your webshop needs a corresponding payment method configured in your ERP. This is the account that will receive the payment when an invoice is marked as paid. You configure the mapping between e-commerce payment types and ERP payment methods in Configure > Settings.
For example, if your store accepts Klarna, card payments, and Swish, you would create three separate payment method accounts in your ERP and map each one in Junipeer.
Fee account
The fee account is where payment provider fees are booked. This should be an expense account in your ERP chart of accounts, typically something like "Payment processing fees" or "Transaction costs." Configure this in your payment method settings.
Make sure this account exists in your ERP before enabling payout reconciliation. If it is missing, fee write-offs will fail and the payout will not balance.
Write-off reason code
Some ERP systems require a write-off reason code to process fee deductions. In Junipeer, this is configured via the FeeWriteOffReasonCode setting. Check your ERP's documentation for the available reason codes and select the one that best describes payment processing fees.
Payout flow activation
The payout reconciliation flow must be activated in Flows. Look for the "Export Payouts" flow for your ERP destination. This flow handles receiving payout reports and executing the matching process.
Payment date logic
When recording a payment against an invoice, Junipeer needs to determine which date to use. The priority order is:
Payment provider date — the date the payment provider recorded the transaction (highest priority)
Order date — the date the order was placed in the e-commerce platform
Sync date — the date Junipeer processed the order (lowest priority, used as fallback)
This matters because your ERP may reject a payment if its date is earlier than the invoice date. If the payment provider recorded the transaction before Junipeer created the invoice, you may see a "Payment date is before the invoice date" error. See the Error Codes guide for how to handle this.
Adding a new payment provider
When you add a new payment provider to your webshop (for example, switching from one buy-now-pay-later provider to another, or adding a new card processor), the order in which you configure things matters.
Always configure the new payment provider in Junipeer before activating it in your e-commerce platform. If you activate the provider in your webshop first, orders will start flowing through before Junipeer knows how to handle them. This causes incorrect payout references on those early transactions, which then fail to match during reconciliation.
The correct sequence is:
Add the payment method account in your ERP
Map the new payment method in Junipeer's settings
Verify the payout flow configuration includes the new provider
Only then activate the provider in your e-commerce platform
If a new provider has already been activated out of order, contact Junipeer support. Historical payout references may need to be corrected in batch.
Multi-currency payouts
Stores that sell in multiple markets often receive payments in different currencies. A store might sell in SEK domestically and EUR internationally, for example. This introduces a complication: the payout currency must match the invoice currency for reconciliation to succeed.
When a payout contains transactions in a currency that differs from the corresponding invoice currency in the ERP, reconciliation fails with a "Could not map payout transaction: Unsupported currency combination" error. This is because your ERP typically requires that the payment amount and the invoice amount are in the same currency.
Multi-market payout reconciliation requires special configuration to handle currency conversions. If you operate multiple markets with different currencies, contact Junipeer support to set up the correct mapping.
Refund payouts
Refunds introduce additional complexity into the payout flow. When a customer receives a refund, the payment provider deducts it from the next payout — reducing the net settlement amount. Junipeer must then:
Match the refund transaction to the correct credit invoice in the ERP
Ensure the credit invoice was created correctly (with all original order rows, discounts, and fees)
Apply the refund amount to the credit invoice
Several things can go wrong here:
Refund created as invoice instead of credit invoice. If the refund flow creates a regular invoice rather than a credit invoice, the accounting is incorrect — the refund appears as revenue instead of a reversal. This is a configuration issue in the refund flow.
Missing rows on credit invoice. If the credit invoice does not include all the rows from the original order — products, discount lines, shipping, return fees — the amounts will not match, and the payout reconciliation for that transaction will fail. Verify that your refund flow is configured to carry over all relevant rows.
Return fees categorized incorrectly. Some integrations may categorize a return fee as a shipping cost on the credit invoice. While the total amount might be correct, the accounting distribution will be wrong. Check the line item mapping in your flow settings if this occurs.
Double-counted refund payouts. In some payment provider and ERP combinations, a refund payout can be applied twice — once as a negative payout line and once as a refund deduction — resulting in a doubled negative balance. If you see invoice amounts that are twice the expected refund, contact Junipeer support with the specific order and payout IDs.
Payment provider–specific notes
Different payment providers have different payout behaviors and API capabilities, which affects how reconciliation works.
Adyen
Adyen's payout API does not provide complete data for all merchants. This means that for some stores using Adyen, automatic payout reconciliation may not be available. If you use Adyen and payout reconciliation is not working, check with Junipeer support to confirm whether your Adyen configuration supports it.
For merchants where Adyen reconciliation is available, configure the Adyen Merchant Portal to send payout webhooks to Junipeer. The relevant event types are payout reports and settlement details.
Buy-now-pay-later providers (Klarna, Qliro, Walley, Svea)
Buy-now-pay-later providers tend to have longer settlement cycles and more complex payout structures. Qliro payouts in particular have been a source of reconciliation issues — if Qliro-paid invoices appear as unpaid in your ERP even though customers have paid, check the Export Payouts flow and verify that the Qliro payout mapping is correctly configured. Large-scale mismatches (hundreds of invoices) may require batch correction by Junipeer support.
Svea refunds have a known pattern where credit invoices may be created as regular invoices. Verify the flow configuration to ensure refunds are mapped to the correct document type.
Card processors
Standard card processors (Stripe, card payment via payment service providers) generally have the most straightforward payout reconciliation. Payouts are typically daily, in a single currency per payout, and the API data is usually complete. If you encounter issues with card payment reconciliation, start by checking the reference number matching — incorrect references are the most common cause of failures.
For troubleshooting common errors, see the Error Codes reference or your connector pair's troubleshooting section.
Best practices
Configure all payment providers in Junipeer before activating them in your webshop. This prevents reference mismatches on historical transactions.
Create a separate payment method account in your ERP for each payment provider. This makes it easier to reconcile bank statements and track provider-specific volumes.
Set up the fee account before enabling payout reconciliation. Missing fee accounts cause the entire payout process to fail.
Review your fee account periodically. Payment provider fees can change, and tracking them helps you compare providers and negotiate better rates.
For high-volume stores, use webhooks for payout ingestion rather than scheduled fetches, to reduce the delay between payout settlement and invoice reconciliation.
Test payout reconciliation with a small batch of transactions before going live. Verify that invoices are marked as paid, fees are written off, and the amounts balance.
When switching payment providers, keep the old provider's mapping in Junipeer until all outstanding payouts have been reconciled. Removing the mapping too early will prevent historical payouts from matching.