PayPal sales reach the ledger but refunds and fees do not: reconcile three separate records

A sale, a refund and a fee are three records

PayPal's payments reference gives each capture a breakdown of gross amount, PayPal fee and the net amount received. A refund is a separate resource: a full refund takes an empty request, a partial refund takes an amount, and several partial refunds can be made until the captured amount is used up. A refund response can carry its own breakdown with gross, fee, net and total refunded amounts when the full representation is requested. An integration that stores only the capture's gross amount will overstate income after the first refund.

Do not recompute the fee

The fee on a refund is not simply the sale fee reversed in proportion. PayPal's transaction event-code reference lists distinct codes for a payment refund and for fee reversal and fee refund, and older PayPal documentation for a legacy refund API says the fixed part of a fee is not returned while the variable part is returned in proportion. That older statement is not confirmed for the current payments API, so the safe rule is to read each refund's fee fields from PayPal and never derive them from a rate.

• Store the PayPal fee as reported on the sale and on each refund.
• Compare ledger net with PayPal net for a test set rather than trusting a fee formula.
• Ask your accountant how a refund and its fee should be recorded before building anything.

Link the records, and expect awkward arrivals

Link each refund to its capture using the identifiers PayPal returns, stored with the sale in your ledger. PayPal's transaction reporting can list two records that share a transaction identifier, one affecting the balance and one not, so a match should use the identifier together with the event code and amount. Refunds can also start outside your integration, for example from the PayPal dashboard, and can arrive before the sale has been recorded. A refund whose sale is missing should be held and retried, not dropped or posted unlinked.

A safe first investigation

Export one month of PayPal activity and the ledger's PayPal account. Total sales, refunds and fees in each. If sales agree but refunds or fees do not, find the first missing refund by date and amount and check whether its sale carries a PayPal identifier in the ledger. Work with a PayPal sandbox or invented records when you test any change; share totals and counts rather than customers.

• A missing identifier on the sale means no refund can be linked automatically.
• Disputes and chargebacks have their own states and are outside this guide.

What fits, what does not, and how it is accepted

The job "Make PayPal refunds and fees appear in the ledger once each, linked to their sale" is from £445, an untested published price confirmed after your enquiry, with payment after the agreed checks pass and you sign off. It is accepted when, in a sandbox month, every refund and partial refund appears once and linked to its sale, ledger net equals PayPal net with any difference listed, a repeated refund event adds nothing, and an early refund is held and posted after its sale.

It does not cover disputes, currency conversion by PayPal or the accounting treatment of refunds and fees. This guide is written from vendor documentation read on 11 October 2026 and nothing was run against a live account. Send invented examples and counts first, never credentials, bank details, invoices or customer records; real records are handled only after written agreement through a secure handoff.