Reference · built on requestOperator by FibricFinance & billing

Payout Reconciliation

Each processor payout tied to its orders, refunds, and fees and to the bank deposit, with entries proposed for every variance.

Request accessPricing ↗

About

A payout is one number that summarizes many. Behind it sit charges, refunds, disputes, fees, and reserve movements, each belonging to an order. This operator reads the payout and its transactions from the processor, the orders those transactions settle in your store, and the deposit the payout became in your ledger's bank account.

It proposes one journal per payout: gross sales, refunds, fees, chargebacks, and reserves, netting to the deposit. Where the deposit differs from the payout, it proposes a variance entry to the account you name. Where an order's payment is in no payout, it lists the order. You approve each journal; the receipt shows the transaction list behind it.

This is a reference listing. It documents what Fibric would read from Payout Reconciliation and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Stripe payouts and the balance transactions in each, by type: charge, refund, adjustment, stripe_fee, reserved_funds, and payout
  • Shopify Payments payouts with status scheduled, in_transit, paid, or failed, and their balance transactions filtered by payout_id
  • Square payouts with status SENT, PAID, or FAILED and their payout entries: CHARGE, REFUND, DISPUTE, FEE, and ADJUSTMENT
  • PayPal transactions from the Transaction Search API with transaction_event_code, transaction_amount, and fee_amount
  • Orders and refunds in Shopify, Magento, or BigCommerce carrying the processor's transaction id
  • Deposits on the bank account in Xero, QuickBooks Online, NetSuite, or Business Central, matched to payouts by date and amount
  • Journals it proposed earlier, so a payout is never booked twice

Proposed actions

  • Target capability: propose a journal per payout: sales, refunds, processor fees, dispute debits, and reserve holds, netting to the deposit
  • Target capability: propose a variance entry where the bank deposit differs from the payout net, coded to the account you name
  • Target capability: propose a fee accrual for charges settled but not yet paid out at period end
  • Target capability: propose a list of paid orders absent from every payout after the interval you set
  • Target capability: propose a note on a Shopify or Magento order naming the payout that settled it

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Book each Stripe payout as one journal

    The balance transactions in a Stripe payout are grouped by type and proposed as a journal in Xero, with the deposit matched by amount and date.

    With Stripe, Xero

  • Shopify Payments to the ledger

    Payouts with status paid are read with their balance transactions, tied to Shopify orders and refunds, and proposed as a QuickBooks Online journal with fees separated.

    With Shopify, QuickBooks Online

  • Find the order that never settled

    Magento orders marked paid through Square with no CHARGE entry in any payout after your interval are listed for the controller.

    With Square, Magento

  • PayPal fees, itemized

    PayPal transactions with fee_amount are reconciled to the NetSuite deposit and proposed as sales, fees, and refunds, with a variance entry where the deposit differs.

    With PayPal, NetSuite

Requirements

  • A processor connector with payouts and their transactions: Stripe, Shopify Payments through Shopify, Square, PayPal, or Adyen
  • A commerce connector for orders and refunds: Shopify, Magento, or BigCommerce
  • A ledger connector with the bank account that receives payouts: Xero, QuickBooks Online, NetSuite, or Business Central
  • Account codes for sales, refunds, fees, disputes, reserves, and variance, agreed before the first journal
  • For Shopify Payments, the shopify_payments_payouts scope on the app you attach
Authentication
It keeps no processor or bank credentials. Payouts, orders, and ledger entries are read through the payment, commerce, and ledger connectors you attach.

Limits

  • A processor's payout day and your ledger's period rarely line up. Transactions are booked to the payout date; you choose the period.
  • Square's Payouts API holds no data before January 2021. Earlier payouts are not read.
  • Refunds paid from a later payout than the charge are booked where the processor puts them, with the original order shown.
  • It books the deposit to the ledger only after approval. The bank feed still records the money arriving.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Payout Reconciliation ↗

Questions and answers

What does the controller approve per payout?
One journal per payout, with the transactions grouped by type, the deposit it matches, and any variance line. You can recode a line, split the variance, or hold the payout for review.
What record is left in the ledger?
A receipt per payout: the transaction ids booked, the journal lines and accounts, the deposit matched, who approved, and when. The reversing journal is described on the receipt.
Does it post journals without approval?
No. Nothing is written to the ledger until a person approves, and each payout is booked once. A payout already booked is recognized and skipped.
Ask about Payout Reconciliation

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy