Job paypal-refunds-missing-from-ledger · revised 11 October 2026
Make PayPal refunds and fees appear in the ledger once each, linked to their sale
In a sandbox month with sales, a full refund and partial refunds, every PayPal refund and fee reaches the ledger exactly once, linked to its sale, and ledger net equals PayPal net.
You might be seeing
- Ledger income for PayPal is higher than money actually received after refunds
- A refund started from the PayPal dashboard never appears in the accounting system
- Fees are missing or posted once as a sale-side figure and never reversed when a refund is issued
No passwords, keys, card details or admin invites needed to start.
What usually happened
The integration records each PayPal capture as a sale but does not turn refunds, partial refunds or the fee changes that come with them into linked ledger entries. Refunds can start outside the integration, events can repeat or arrive before the sale exists, and nothing connects a refund record back to the capture it reduces.
Who it’s for: A bookkeeper, shop owner or finance manager whose PayPal sales reach the accounting system but whose refunds and fees do not, so the ledger shows more income than the PayPal balance.
Usually starts when: Month-end PayPal activity does not agree with the ledger: sales match, but refunds, partial refunds and fees leave a difference that grows each month.
The result: For an agreed sandbox month, each refund and fee movement in PayPal exists once in the ledger as an entry linked to its original sale, a replayed refund event adds nothing, and the ledger net equals the PayPal net for that set.
Check whether this job fits
Answer these from what you can see without sending logins, invoices or customer data. Nothing is submitted unless you choose to contact us; this is a fit check, not permission for us to touch your systems.
Checks you can run yourself
Reconcile one month by hand
Export one month of PayPal activity and one month of the ledger's PayPal account. Compare totals for sales, refunds and fees. Do not share the exports.
Look for: Which of the three totals differs. A refund or fee difference with matching sales is the failure this job fixes.
What you get
- The change as a pull request or exported configuration, with the linking rule and the fee rule described
- A sandbox-month reconciliation sheet: sales, refunds, partial refunds, fees, ledger net and PayPal net
- A list of events held or replayed during the tests, with the reason
Included
- One PayPal account feeding one Xero organisation or QuickBooks Online company for one currency
- Mapping of refund and partial-refund records to credit entries linked to the original capture by its PayPal identifiers
- Fee handling from the amounts PayPal reports on the sale and on the refund, never recomputed from a rate
- Event handling that records each PayPal event id once, holds a refund whose sale is not yet recorded, and can replay a missed window from the transaction report
- Tests with PayPal sandbox or invented records and a demo or sandbox ledger
Not included
- Disputes, chargebacks and holds, which have separate rules and are not part of this scope
- Currency conversion by PayPal into another balance currency
- Choosing how refunds, fees or sales tax are treated in your accounts: your accountant decides
- Historic months already reconciled by hand, unless agreed as a backfill
- Bookkeeping, tax, audit or any accounting advice, including deciding how a transaction should be treated in your accounts
- Changing posted, reconciled or locked-period transactions: your accountant or account holder decides and performs those
- Live changes: your authorised account holder applies any agreed change and holds the production keys
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
In the sandbox month, every refund and partial refund appears once in the ledger, linked to the PayPal identifier of its sale, and the count matches PayPal's refund count.
Evidence: The PayPal refund list, the ledger entries and a per-refund link table.
Ledger net for the test set equals PayPal net after fees and refunds, with any difference listed line by line.
Evidence: The reconciliation sheet with sales, refunds, fees and both nets.
Delivering the same refund event twice, and replaying the month from the report, adds no entry.
Evidence: Entry counts before and after each repeat.
A refund event delivered before its sale is held, then posted after the sale exists, with no loss.
Evidence: The held list entry and the final ledger entry with timestamps.
Sign-off. You inspect the named test evidence and sign off before payment. Your authorised account holder performs and verifies any live change, and decides what happens to records already posted.
If it fails. If an agreed check does not pass, you do not pay for this fixed scope. We hand over the findings and agree whether to stop or re-quote; no surprise work and no change to your live records.
When it fits, and when we stop
It fits when
- Sales already reach the ledger with a PayPal identifier stored on them, or one can be added as part of scope
- PayPal sandbox access or invented records and a demo or sandbox ledger are available for the tests
- Your bookkeeper can say how a refund and a fee should appear, for example as a credit note and a fee expense
- A person on your side approves the linking and fee rules before work starts
- Real financial records, customer data and keys are handled only after written agreement, through a secure handoff we agree with you; the first enquiry and the fit check use invented or redacted examples
We stop and tell you if
- Sales are not stored with any PayPal transaction or capture identifier and none can be added
- Refunds are issued in a currency different from the sale, which needs a separate design
- The account relies on features the sandbox cannot reproduce and no invented records can stand in
What could go wrong
Before merge, closing the pull request leaves your integration unchanged. After merge, your developer can revert it and your accountant can reverse the entries it created, which are listed by PayPal event id. The sandbox ledger is disposable.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A refund is posted twice because the same event is delivered again or a missed window is replayed. | Each event id is recorded once and refunds are keyed by refund id; the duplicate-event and replay cases are named acceptance tests. |
| Fees are recomputed from a rate and drift from what PayPal actually charged or returned. | Fee amounts come from the sale and refund records PayPal returns; no rate is applied by the job. |
| A refund arrives before its sale is in the ledger and is dropped. | Such a refund is held and retried when the sale appears, and the held case is a named acceptance test. |
An independent reviewer recomputes the net for the test month from the PayPal records, checks that a repeated event adds nothing, and confirms a refund can never post before its sale. Your accountant approves the entry types.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the linking rule, the fee rule and the entry types for refunds and fees with your accountant in writing
- Reproduce the gap with a sandbox month containing sales, a full refund and partial refunds, and record the ledger and PayPal totals
- Link each refund to its capture by PayPal identifier and record fees from the amounts PayPal reports
- Record each PayPal event id once, hold a refund whose sale is missing and test a replay from the report
- Run the sandbox month and compare ledger net with PayPal net
- Independent review of the sums and the event handling, then hand over for your developer to merge and your accountant to approve
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Platform and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
If PayPal volume is steady, discuss a monthly check that refunds and fees agree with the ledger as a separate standing agreement.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- PayPal's Transaction Search API lists activity for a date range, including fees and refund event codes, which your developer can use to build a month-end comparison. developer.paypal.com
- Ask the maker of your accounting connector whether it records PayPal refunds and fees; many do for sales only.
Questions
Do you handle PayPal disputes?
Not in this scope. Disputes and holds have their own states and need a separate quote.
Can PayPal events arrive late or twice?
PayPal documents retrying failed webhook deliveries for several days, so duplicates and late arrivals are expected. The job records each event once and can replay a window from the transaction report.
Does this decide how refunds are taxed?
No. It records what PayPal reports. Your accountant decides the treatment of refunds, fees and any sales tax.
Send an enquiry
Send us
- How sales arrive in the ledger today and whether a PayPal id is stored with them
- An invented sale with one full refund and one partial refund, with amounts and fees that add up
- Whether refunds are issued from your site, from the PayPal dashboard or both
- Do not send credentials, bank details, invoices, customer records or confidential code in the first enquiry
Later, once you agree
- PayPal sandbox credentials created by you and a webhook endpoint or report export arranged through the agreed route
- A demo organisation or sandbox ledger created by you for the job
- Your accountant's written rule for how refunds and fees are recorded
- A secure, company-controlled handoff route agreed in writing before any access; no passwords, keys or customer records by ordinary email
You keep the live accounting organisation, payment accounts, production keys and every customer and financial record. We work on an authorised demo, sandbox or synthetic copy through a company-controlled handoff, never a personal login. Your authorised account holder approves and performs any live change and checks the result under their own keys.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “paypal-refunds-missing-from-ledger” as the subject.