Skip to content
PartnerMCPPartnerMCP

§00Payments reconciliation

Solutions

Every payment matched. Every payout explained.

Stripe pays out net of fees, refunds and disputes. Your ERP needs each payment against its invoice and each deposit explained to the cent. PartnerMCP builds the matching — and holds what it can’t match for a person instead of guessing.

Build this integrationStripe ↔ Priority
Stripe payout po_…7Hk2
Production

Explained

Payments12 charges
48,210.00
Stripe feesBalanceTransaction.fee
−1,412.33
Refunds1 refund
−640.00
Dispute1 dispute
−395.00
Net payout = bank deposit
45,762.67

Matched to invoices · 4 of 12

  • pi_…4821 → IN-24817exact reference4,800.00
  • pi_…4822 → IN-24822customer + amount1,250.00
  • pi_…4830 → IN-24829held · partial · 620 of 1,240620.00
  • pi_…4833 → —held · no open invoice2,100.00
10 posted · 2 waiting for a person12 payments
Product preview · sample data
§01—Why it’s hard

Payment events don’t balance the books on their own.

Closing invoices and explaining deposits are two different jobs, on two different clocks. PartnerMCP does both.

Invoice clock

Did the customer pay?

  1. payment_intent.succeededStripe says the customer paid
  2. receiptposted against the open invoice
  3. invoice closedin the ERP

Bank clock

What reached the bank?

  1. BalanceTransactionfee · net · available_on
  2. payout.paidnet of fees, refunds and disputes
  3. deposit matchedto the cent, line by line

One charge, two clocks. Payment events can close an invoice; only the payout’s balance transactions explain the deposit — so PartnerMCP reads both.

§02—Matching

Rules you can read. A person when it isn’t sure.

Matching is written into the integration as explicit rules, in order — and anything that doesn’t meet them waits for review.

  1. 01Exact reference

    The invoice reference travels with the payment — a Stripe invoice, or the number your checkout passed along. An exact match posts the receipt.

  2. 02Customer and amount

    No reference? The same customer, the same amount and one open invoice in the window: a match, with its confidence and reason recorded.

  3. 03Everything else waits

    Partial and over-payments, one payment for several invoices, no open invoice at all: held for a person, with the likely candidates ranked. It never guesses with money.

Stripe → Priority ERP
Payment succeededInvoice matchAmounts & feesPost receiptClose invoiceReconcile payoutsExceptionsMark reconciled
Payments reconciliation plan: Stripe to Priority ERP. Stripe to Priority ERP.
  1. Payment succeeded — Stripe: Trigger · webhooks
  2. Invoice match — PartnerMCP: Invoice ⇄ AINVOICES
  3. Amounts & fees — PartnerMCP: currency · fees · partials
  4. Post receipt — Priority ERP: TINVOICES
  5. Close invoice — Priority ERP: AINVOICES
  6. Reconcile payouts — PartnerMCP: payouts · fees · refunds
  7. Exceptions — PartnerMCP: unmatched → review queue
  8. Mark reconciled — Stripe: PaymentIntent
Product preview · sample data
§03—Events

Every Stripe event, handled.

What PartnerMCP does when each event arrives — and what it does when one arrives twice, late, or not at all.

payment_intent.succeeded
Match the payment to its open invoice and post the receipt.
invoice.paid
Close the matching invoice in the ERP.
charge.refunded
Record the refund against the original invoice — held for review if that invoice is already closed.
charge.dispute.created
Hold the receipt and flag the customer for finance.
payout.paid
Reconcile the payout: every balance transaction to its receipt, fee or refund, until the total equals the deposit.

Delivery, the way Stripe really sends it

  • Stripe retries a delivery for up to three days in live mode and doesn't guarantee order, so the same event can arrive twice or late. PartnerMCP de-duplicates on the event ID and checks for a receipt it already posted.
  • Every delivery is verified against its Stripe-Signature header before it is trusted.
  • Anything a delivery missed is caught by listing recent objects with Stripe's cursor pagination.

On the ERP side

  • Priority ERP

    Receipts applied to open sales invoices (AINVOICES). The receipts form, TINVOICES, comes from real installations rather than Priority's published docs — verified on your tenant first.

  • Oracle NetSuite

    A customerPayment applied to the open invoice, through SuiteTalk REST — within the account's shared concurrency.

§04—FAQ

Questions

Does PartnerMCP move money?

No. In this flow it reads payments and payouts from Stripe and posts accounting records in your ERP. It doesn’t issue refunds or payouts — and where Stripe’s own MCP server is involved, Stripe requires a person to confirm refunds and outbound payments anyway.

What happens to a payment it can’t match?

It waits in a review queue with the likely invoices ranked and the reason it wasn’t matched. A person decides; the decision is recorded with the payment.

How are fees and refunds posted?

Each balance transaction carries its fee and net amount, so fees and refunds are posted as their own lines, to the accounts your finance team chooses when the integration is set up.

Which ERPs does this work with?

Any ERP with an API. The worked examples are Priority ERP receipts and NetSuite customer payments; the same rules apply to SAP, Dynamics 365 and others.

Is this only for Stripe?

Stripe is the worked example. The same approach — events to close invoices, settlement data to explain deposits — applies to other payment providers with an API, such as PayPal.

§05Build

Every payout, explained in your ERP.

Describe how payments should land in your ERP. PartnerMCP shows the matching rules and the plan before anything is built.

Build this integrationTalk to an engineer