Accounting & reconciliation

Keep the books tied to reality. The platform records the journal activity behind funding, collections, and payouts, and helps you reconcile against the bank.

Journal entries

Money-moving events post journal entries with balanced debits and credits, in integer cents. This gives you a ledger you can trust without exporting to a spreadsheet first.

Bank reconciliation

Match posted activity against your bank statement to confirm what actually cleared. Reconciliation surfaces discrepancies - missing deposits, unexpected returns - so nothing slips through.

Statements

Schedule periodic merchant statements summarizing balance and activity. The worker generates and sends them automatically on the cadence you choose, so merchants always know where they stand.

A deal's payment statement

In a deal's payments, Download CSV gives staff every row — partner payouts included — in date order with the balance after each. Statement PDF is for the merchant: an account summary and their cleared and returned payments and fees, with your document design. Tick with pending & upcoming to add payments in process, unpaid fees, the next payment and the pulls still to come. Partner payouts, internal entries and cancelled rows never appear, and a pending pull dated before today is never printed. Needs view payments.

Payment types

Every row on a deal ledger has a type that decides where it lands in accounting and reports:

The same descriptions appear as hover tooltips on the type dropdowns on a deal's ledger. Payback types count toward collections and the running balance; fee types count as fee income; payout types are money out to participants.

Bounces & make-up payments

When a pull bounces and the merchant later catches up (a wire, a re-pull), the books keep both facts — the return and the recovery — without rewriting either:

• The bounce stays a bounce. It keeps its original due date (the scheduled date) and its return code. That's your NSF history; it never disappears.
• The catch-up payment keeps its real paid date. Cash is never back-dated: the wire cleared the day it cleared, and bank reconciliation, collected-in- period reports and syndicator splits all depend on that real date.
• The link is what resolves it. On the deal ledger, use Make up… on the bounced row to point it at the PAID payment that covered it (one catch-up wire can cover several bounces). The bounce then shows due date (its own) and paid date (the covering payment's).

The dashboard counts only outstanding bounces in red — made-up bounces move to a green "made up" tag but stay in the return history and the by-reason chart. Unlinking (✕) puts the bounce back in the outstanding count.

Fees taken at funding vs. add-on fees

• At funding — wire, UCC, application and the bank/origination fee. They come out of the funding on the funding day and are never owed afterwards.
• Add-on — charged after funding: an incoming-wire cost passed to the merchant, bounce/NSF fees and the like. They are owed on top of the payback and never change the payback, outstanding balance, % paid or syndicator shares; the money is the house's.

The deal's Fees card lists the add-on fees and the total owed (payback plus unpaid add-on fees). Recording a payment by wire offers the incoming-wire fee ($15 by default, a company setting) as Charge merchant (a pending add-on fee) or House absorbs (expense).

Accounting → Fee review lists every funded deal's bank, wire, UCC and application fee, how the money went out (wire or ACH, and what sending cost) and any referrer cut. Filter to deals missing a fee, Fill blanks with defaults (only blanks; the application fee is never guessed), Save, or Export CSV. Saves go through the same rules as editing the deal; a funding already in the journal is corrected through Reconcile.

Overpayments

When a deal has collected more than its payback plus add-on fees, a banner says by how much and how much is still unassigned. Until someone decides, it is held for the merchant — not house income, and syndicators never share in it. Decide where it goes refunds part to the merchant (ACH, wire, check…, never future-dated), keeps part as house income, or splits it; add-on fees still owed are paid out of the overage at the same time. Apply to renewal moves it to the merchant's renewal as an extra payment. Refunds need the record refunds permission; without it the refund choice is not offered.

Schedule health and rebuild

Accounting → Schedule health compares each deal's remaining schedule with its real pulls. Nothing changes until you press a button. It reports:

• scheduled pulls already paid by an imported pull on the same day, and past-due pulls with no payment that day;
• days with two cleared pulls (with the processor references);
• a pending schedule more or less than the balance left to collect;
• a schedule different from MCAPay's active schedule, or a deal linked to MCAPay with none there;
• defaulted deals with pending pulls (kept, never cancelled).

Repair cancels only scheduled pulls a processor pull already covered on the same day and amount — a hand-keyed payment never counts — and tidies legacy row types. Past-due pulls with no payment are listed for a person to decide.

Rebuild… replaces a funded deal's unclaimed pending pulls with equal pulls for exactly what is left (payback − collected − in flight; the last pull is the exact remainder). When the deal is linked to MCAPay it follows MCAPay's amount, frequency and next date, otherwise the deal's terms. You see the plan and any warnings first; old pulls are cancelled but kept on record, and pulls already submitted to the processor are never touched. Defaulted deals are refused — their pending pulls stay. Download CSV exports every deal, MCAPay columns included. Needs access accounting.

Projected P&L and partner profit splits

The Projected P&L report (Reports → Investors & house) projects collections and who keeps what. In Who gets what:

• Per-deal profit split — partners on per-deal settlement split each deal's profit as it collects.
• Monthly P&L split — partners on Monthly P&L settlement (set on the syndicator: their share of the P&L % and first statement on) split the pooled profit instead; a loss stays theirs. Until the first statement, all profit and loss on their share sits in their wallet.
• The house has two lines: the house (its own capital, plus the profit split and fees from partners) and the house syndication account. View: House only shows both.

Can’t find what you need? Return to the app or contact your administrator.