--- oa_review_kit: v1 guide_slug: global-payment-processors guide_version: global-payment-processors@2026-04-13T17:56:45.763Z archetype: other --- # Review kit: Global Payment Processors Thank you for reviewing this Guide. This kit is one file with three parts: how to use it, an interview prompt for your AI, and the Guide itself. ## How to use this kit (3 steps, about 15 minutes) 1. Open the AI you already use (ChatGPT, Claude, Gemini, anything that reads markdown) and paste in everything from "INTERVIEW PROMPT" below, including the Guide at the end. 2. Your AI interviews you like a colleague, one question at a time. Just talk: war stories, walk-throughs, the mistakes you catch. No writing required. 3. Your AI writes your answers up as a single markdown file. Hand it back at openaccountants.com/skills/global-payment-processors/handback (also linked from the Guide page: "Hand back your file"). What you added is published under your name and credential. If your AI cannot produce the exact output format, hand back whatever you have: a revised Guide file, a worksheet, or plain notes. We take those too, and a person reviews them by hand. The format below is the one we can apply straight away. --- # INTERVIEW PROMPT (paste from here down into your AI) You are interviewing a practising accountant about how they actually do the work covered by the attached Guide ("Global Payment Processors", slug `global-payment-processors`). Interview them like a colleague doing a handover. Do not lecture. Ask ONE question at a time and wait for the answer. Chase war stories and specifics: what kind of client, which portal step, how big the penalty was. The rates, thresholds, and citations are our job; we refresh those from primary sources. Capture ONLY what is NOT derivable from law: - order of operations, and what a wrong order corrupts - what to ask a client before computing anything - what to assume when a fact is unknown, and how it gets flagged - the most-missed traps, with penalty size and who falls in - how the portal or filing channel actually behaves - what has to reconcile before anyone signs - when to refuse the work and hand it to a human specialist If the accountant corrects a rate, threshold, or deadline in the Guide along the way, record it in the FACT CORRECTIONS table, but do not steer the interview toward numbers. ## Questions to work through Ask these in order, one at a time. Skip any the accountant has already covered; follow up where a story has specifics worth pinning down. Each question is tagged with the method slot(s) it feeds. 1. [sequence] Walk me through the last one of these you did for a real client, start to finish. What did you open first, and why that order? 2. [intake_questions] A new client sits down for this work. What are your first five questions before you touch a number? 3. [evidence] Which documents do you insist on seeing, and which do you take the client's word for? 4. [trap] When you review this work drafted by someone else, what mistake do you catch most often? 5. [conservative_default] When a key fact is unknowable at draft time, what do you assume, and how do you flag it? 6. [judgment_rule] When the law allows two routes, how do you actually pick, and what do you write down about the choice? 7. [cross_check] Before you sign, what has to reconcile with what, and how close is close enough? 8. [filing_mechanics] Walk me through the actual submission: the portal steps, the order things must happen in, what locks, what you can't undo. 9. [scope_gate] Which clients do you refuse or refer to a specialist for this work? What makes you stop? 10. [unsettled_law] Anything here you deliberately won't finalise right now because the rules are moving? 11. [handback_protocol] What exactly do you hand over at the end? What's in your working paper? ## Method slots (for tagging the write-up) - `scope_gate` (Scope gate and refusals): when to stop and send the client to a human - `sequence` (Order of operations): what order to do things in, and what a wrong order corrupts - `intake_questions` (Client intake questions): what to ask a client before computing - `evidence` (Documents and evidence): which documents to insist on, and what is draft-grade vs file-grade - `judgment_rule` (Judgment rules): how a practitioner actually picks when the law allows two routes - `conservative_default` (Conservative defaults): what to assume when a fact is unknowable at draft time - `trap` (Traps and most-missed items): the mistakes everyone makes, what they cost, and who falls in - `filing_mechanics` (Portal and filing mechanics): how submission actually works: channel, order, what locks - `cross_check` (Cross-checks before signing): what has to reconcile with what before delivery, and how close is close enough - `pattern_library` (Pattern library): how messy real-world data (bank lines, payout platforms) maps to tax categories - `edge_case` (Edge-case playbook): the client situations that change the method, not just the numbers - `unsettled_law` (Unsettled-law flags): what not to finalise right now, and why - `handback_protocol` (Hand-back protocol): what the finished working paper contains and who reviews it ## Output format: oa-handback v1 When the interview is done, write the answers up as ONE markdown file in exactly this shape. Fill in the reviewer's real name, credential, and email (ask for them at the end if they have not come up). Every method block gets a `### [method:]` heading where `` is one of the 13 slot ids above. Keep `guide_slug` and `guide_version` exactly as given. Omit any section the interview produced nothing for, but keep the headings that remain exactly as shown. The `fact_key` column may be left blank when unknown. ```markdown --- oa_handback: v1 guide_slug: global-payment-processors guide_version: global-payment-processors@2026-04-13T17:56:45.763Z reviewer_name: reviewer_credential: # free text: CPA, EA, ACCA, Steuerberater... reviewer_email: verdict: --- ## METHOD ### [method:filing_mechanics] ### [method:intake_questions] - - ... ## FACT CORRECTIONS | fact_key | current | correct | source | |---|---|---|---| | | | | | ## FLAGS - [unsettled] - [refer] ## NOTES ``` If for any reason you cannot produce this exact format, output the accountant's corrections and methods as clear plain notes instead. The hand-back page accepts plain notes and revised Guide files too; this format is an optimization, never a gate. --- # THE GUIDE UNDER REVIEW --- name: global-payment-processors description: Classification rules for payment processor transactions — the number one source of bank statement classification errors. Covers Stripe, PayPal, Wise, Square, SumUp, iZettle, Revolut, GoCardless, Paddle, Gumroad, and LemonSqueezy with worked examples for reconstructing gross revenue from net payouts. jurisdiction: GLOBAL tax_year: 2025 --- # global-payment-processors ## What this file is **Functional role:** Transaction classification rules for payment processor entries **Status:** Active reference data Payment processor transactions are the single largest source of classification errors in freelancer bookkeeping. The core problem: **a payout from Stripe/PayPal/etc. is NOT your revenue. It is your revenue MINUS their fees.** If you book the payout as revenue, you understate revenue AND miss a deductible expense. This file provides deterministic rules for every major payment processor, explains what each transaction type actually represents, and includes worked examples for reconstructing the correct accounting entries. ## The golden rule - **Golden rule for processor payouts** — Bank deposit from a payment processor = Net payout = Gross revenue - Processing fees. You must record: 1. Gross revenue (what the customer paid) 2. Processing fee (deductible expense) 3. Net payout (what hit your bank — this is NOT a revenue figure). If you only have the bank statement (no processor dashboard), you are missing data. You MUST obtain the processor's transaction report to book correctly. _(The golden rule section)_ ## Processor lookup table **Processor lookup table** _(Processor lookup table)_ | Processor | Bank statement text | What it IS | What it is NOT | Classification rule | | --- | --- | --- | --- | --- | | **Stripe** | `STRIPE PAYMENTS`, `STRIPE TRANSFER`, `STRIPE PAYOUT` | Net payout after Stripe fees (typically 2.9% + 30c per transaction, varies by country/product) | NOT gross revenue. NOT a Stripe subscription fee. | Book gross revenue from Stripe dashboard. Book Stripe fees as "Bank charges / Payment processing fees". The bank deposit is merely the settlement. | | **Stripe** | `STRIPE CONNECT` | Payout from a Stripe Connect platform (e.g., marketplace payout) | NOT revenue from YOUR customers. The platform is paying you. | Revenue = payout + platform fees withheld. Check platform dashboard for gross amounts. | | **Stripe** | `STRIPE ATLAS` | Stripe Atlas incorporation service fee ($500 one-time + optional ongoing) | NOT a payment processing charge. | One-time: Capitalize as incorporation cost or expense as startup cost. Ongoing: Office expenses / Legal services. | | **Stripe** | `STRIPE *INVOICE`, `STRIPE BILLING` | Stripe's invoicing/billing product collecting payment on your behalf | NOT revenue — same net-payout rule applies. | Same as standard Stripe payout rule. | | **PayPal** | `PAYPAL TRANSFER`, `PAYPAL INST XFER` | Net payout from PayPal balance to bank account | NOT revenue. This is a transfer between your own accounts. | The revenue was already recorded when the customer paid into your PayPal account. This transfer is a balance movement, not income. | | **PayPal** | `PAYPAL *[MERCHANT]` | Payment TO a merchant via PayPal (expense) | NOT revenue. NOT a PayPal fee. | Classify based on the merchant name after the asterisk. This is an expense paid via PayPal. | | **PayPal** | `PAYPAL PAYMENT` | A payment received via PayPal (shows on PayPal statement, not always on bank) | The net amount (after PayPal's fee of ~2.9% + fixed). | Gross revenue = net received + PayPal fee. Obtain PayPal transaction report for exact fee breakdown. | | **PayPal** | `PP*[CODE]` | PayPal charge — could be incoming or outgoing | Ambiguous — must check direction and reference. | Check debit/credit. If debit: expense. If credit: net payout (not revenue). | | **Wise** | `WISE`, `TRANSFERWISE` | Currency conversion / international transfer | NOT revenue. NOT an expense (unless the Wise fee itself). | If sending money: the transfer is a payment for an expense (classify the underlying expense). If receiving: it is a client payment arriving via Wise. The Wise fee is a separate deductible "Bank charges / FX fees" expense. | | **Wise** | `WISE *FEE`, `TRANSFERWISE FEE` | Wise's transfer fee | NOT the transfer amount itself. | Deductible as "Bank charges / Transfer fees". | | **Wise** | `WISE CURRENCY` | FX conversion within Wise multi-currency account | NOT revenue or expense. It is a balance conversion. | Book the FX gain/loss. The conversion itself is not income or expense — only the exchange rate difference matters. | | **Square** | `SQ *`, `SQUARE`, `SQUAREUP` | Net payout from Square card reader | NOT gross revenue. | Same pattern as Stripe. Gross revenue = payout + Square processing fee (typically 2.6% + 10c US). Obtain Square dashboard report. | | **Square** | `SQUARE HARDWARE` | Purchase of Square card reader hardware | NOT a payment processing fee. | Capitalize as equipment (if material) or expense as office supplies. | | **SumUp** | `SUMUP`, `SUMUP *` | Net payout from SumUp card reader | NOT gross revenue. | Same pattern. SumUp fee varies by country (1.69% EU typical). Check SumUp dashboard. | | **iZettle** | `IZETTLE`, `ZETTLE`, `PAYPAL ZETTLE` | Net payout from Zettle (now PayPal Zettle) card reader | NOT gross revenue. | Same pattern. Now owned by PayPal. Fee typically 1.75% EU. | | **Revolut Business** | `REVOLUT`, `REVOLUT *` | Transfer between Revolut and external bank, or Revolut account fee | NOT revenue. NOT an expense (unless it is the account fee). | If a transfer to/from your own account: ignore for P&L (balance movement). If a fee: "Bank charges". If a payment to a supplier: classify by supplier. | | **Revolut Business** | `REVOLUT *PREMIUM`, `REVOLUT *METAL` | Revolut subscription fee | NOT a transfer. | "Bank charges / Account fees". Verify business vs. personal plan. | | **GoCardless** | `GOCARDLESS`, `GOCARDLESS LTD` | Direct debit collection payout | NOT gross revenue. GoCardless deducts its fee before payout. | Gross revenue = payout + GoCardless fees (1% + 20p typical UK). Obtain GoCardless report. | | **GoCardless** | `GOCARDLESS *[CLIENT]` | A direct debit payment collected FROM you by a vendor using GoCardless | This is an EXPENSE, not revenue. | Classify based on the vendor name. Common for recurring SaaS bills collected via DD. | | **Paddle** | `PADDLE.NET`, `PADDLE COM` | Payout from Paddle as Merchant of Record (MoR) | NOT your gross revenue. Paddle invoiced the customer, not you. YOUR revenue is the net payout from Paddle. | Paddle is the legal seller. They handle VAT, refunds, chargebacks. Your revenue = Paddle payout. Paddle's cut includes their fee + taxes they remitted. Do NOT also record the customer's gross payment as your revenue. | | **Gumroad** | `GUMROAD`, `GUMROAD INC` | Payout from Gumroad as MoR | NOT your gross revenue. Same MoR pattern as Paddle. | Revenue = Gumroad payout. Gumroad handles sales tax/VAT and takes their commission. | | **LemonSqueezy** | `LEMONSQUEEZY`, `LEMON SQUEEZY`, `LMSQUEEZY` | Payout from LemonSqueezy as MoR | NOT your gross revenue. Same MoR pattern. | Revenue = LemonSqueezy payout. They handle all tax obligations as MoR. | | **Shopify Payments** | `SHOPIFY *PAYMT`, `SHOPIFY PAYOUT` | Net payout from Shopify Payments | NOT gross revenue. | Same as Stripe pattern. Shopify Payments fee is separate. Note: Shopify subscription fee is a different charge (SaaS expense). | | **Amazon Pay** | `AMZN *PAY`, `AMAZON PAY` | Payout from Amazon Pay | NOT gross revenue. | Revenue = payout + Amazon Pay fees. | | **Klarna** | `KLARNA`, `KLARNA AB` | Payout from Klarna (buy-now-pay-later) | NOT gross revenue. Klarna pays you in full (minus fee) even though customer pays in installments. | Revenue = Klarna payout + Klarna merchant fee. You recognize full revenue at sale, not when customer completes installments. | | **Adyen** | `ADYEN`, `ADYEN N.V.` | Payout from Adyen payment platform | NOT gross revenue. | Same net-payout pattern. Adyen fees deducted. | | **Mollie** | `MOLLIE`, `MOLLIE B.V.` | Payout from Mollie payment platform | NOT gross revenue. | Same pattern. Common in NL/EU. | ## Worked examples ### Example 1: Stripe payout reconstruction **Bank statement shows:** ``` 2025-03-15 STRIPE TRANSFER +$4,721.50 ``` **Stripe dashboard shows for the same payout period** _(Example 1: Stripe payout reconstruction)_ | Customer | Gross amount | Stripe fee | Net | | --- | --- | --- | --- | | Client A invoice #42 | $2,500.00 | $75.30 | $2,424.70 | | Client B invoice #18 | $1,800.00 | $54.60 | $1,745.40 | | Client C invoice #7 | $575.00 | $23.60 | $551.40 | | **Total** | **$4,875.00** | **$153.50** | **$4,721.50** | **Correct bookkeeping entries** _(Example 1: Stripe payout reconstruction)_ | Date | Account | Debit | Credit | Description | | --- | --- | --- | --- | --- | | 2025-03-15 | Revenue | | $4,875.00 | Gross client payments (3 invoices) | | 2025-03-15 | Bank charges - Processing fees | $153.50 | | Stripe processing fees | | 2025-03-15 | Bank (checking) | $4,721.50 | | Stripe payout received | **WRONG approach (common error)** _(Example 1: Stripe payout reconstruction)_ | Date | Account | Debit | Credit | | --- | --- | --- | --- | | 2025-03-15 | Revenue | | $4,721.50 | | 2025-03-15 | Bank (checking) | $4,721.50 | | This understates revenue by $153.50 AND misses $153.50 in deductible expenses. The tax impact compounds: the missed deduction means the freelancer overpays tax on $153.50 of phantom income. ### Example 2: PayPal with embedded fees **Bank statement shows:** ``` 2025-04-01 PAYPAL INST XFER +EUR 1,890.00 ``` **PayPal transaction report shows** _(Example 2: PayPal with embedded fees)_ | Date | Type | Gross | Fee | Net | | --- | --- | --- | --- | --- | | 2025-03-28 | Payment received | EUR 1,000.00 | -EUR 29.20 | EUR 970.80 | | 2025-03-29 | Payment received | EUR 950.00 | -EUR 27.85 | EUR 922.15 | | **Subtotal** | | **EUR 1,950.00** | **-EUR 57.05** | **EUR 1,892.95** | | 2025-03-30 | Currency conversion fee | | -EUR 2.95 | -EUR 2.95 | | **Transfer total** | | | | **EUR 1,890.00** | **Correct entries** _(Example 2: PayPal with embedded fees)_ | Date | Account | Debit | Credit | | --- | --- | --- | --- | | 2025-04-01 | Revenue | | EUR 1,950.00 | | 2025-04-01 | Bank charges - PayPal fees | EUR 57.05 | | | 2025-04-01 | Bank charges - FX fees | EUR 2.95 | | | 2025-04-01 | Bank (checking) | EUR 1,890.00 | | ### Example 3: Paddle as Merchant of Record **Bank statement shows:** ``` 2025-05-10 PADDLE.NET +$3,200.00 ``` **Paddle dashboard shows** _(Example 3: Paddle as Merchant of Record)_ | Customer | Country | Gross sale | VAT collected | Paddle fee (5%) | Net to you | | --- | --- | --- | --- | --- | --- | | Customer DE | Germany | $1,200.00 | $228.00 | $60.00 | $912.00 | | Customer US | USA | $1,500.00 | $0.00 | $75.00 | $1,425.00 | | Customer UK | UK | $1,100.00 | $220.00 | $55.00 | $825.00 | | **Total** | | **$3,800.00** | **$448.00** | **$190.00** | **$3,162.00** | Wait — the bank shows $3,200.00 but the table shows $3,162.00? Check if Paddle bundles multiple payouts or if there is a timing difference. Always reconcile. **Key difference from Stripe/PayPal:** Paddle is the Merchant of Record. Paddle invoiced the customers, collected VAT, and remitted it. YOU do not report the $3,800 gross or the $448 VAT. Your revenue is the $3,162 payout. Paddle's fee is already deducted — you do NOT separately claim a Paddle fee expense. **Correct entries** _(Example 3: Paddle as Merchant of Record)_ | Date | Account | Debit | Credit | | --- | --- | --- | --- | | 2025-05-10 | Revenue | | $3,162.00 | | 2025-05-10 | Bank (checking) | $3,162.00 | | That is it. No fee expense. No VAT. Paddle handled everything. ### Example 4: Wise international transfer with FX **Bank statement shows:** ``` 2025-06-01 WISE +GBP 7,850.00 ``` **Wise transfer details** _(Example 4: Wise international transfer with FX)_ | Field | Value | | --- | --- | | Client paid | USD 10,000.00 | | Exchange rate | 1 GBP = 1.2739 USD | | GBP equivalent at mid-market rate | GBP 7,850.03 | | Wise fee (paid by sender) | USD 45.00 | | Amount received | GBP 7,850.00 | - **If the client paid the Wise fee** — Your revenue is USD 10,000.00 (or GBP equivalent at invoice date rate). The Wise fee is the client's cost, not yours. Book revenue at the invoiced amount and any FX gain/loss between invoice date rate and settlement date rate. _(Example 4: Wise international transfer with FX)_ - **If you paid the Wise fee** — Revenue = USD 10,000.00. Wise fee = USD 45.00 (deductible as bank charges). Net received = USD 9,955.00 equivalent. _(Example 4: Wise international transfer with FX)_ ## Merchant of Record vs. Payment Processor — critical distinction **Merchant of Record vs. Payment Processor — critical distinction** _(Merchant of Record vs. Payment Processor — critical distinction)_ | | Payment Processor (Stripe, PayPal, Square) | Merchant of Record (Paddle, Gumroad, LemonSqueezy) | | --- | --- | --- | | **Who invoices the customer?** | YOU do | THEY do | | **Who collects sales tax/VAT?** | YOU must | THEY handle it | | **Who handles refunds/chargebacks?** | YOU handle them, they process | THEY handle everything | | **Your gross revenue** | Customer's full payment amount | The net payout you receive | | **Fee treatment** | Separate deductible expense | Already deducted from your payout — do NOT double-deduct | | **VAT on your sales** | You report and remit | MoR reports and remits — you do NOT include in your VAT return | | **Your invoice** | Issued to customer | Issued to the MoR (or not needed — check your contract) | ## Common mistakes - **1. Booking net payouts as gross revenue** — This is the most common error. It understates revenue AND misses deductible fees. The net tax effect can be zero in simple cases, but it corrupts financial statements and can trigger issues if audited. _(Common mistakes)_ - **2. Double-counting MoR revenue** — If Paddle/Gumroad pays you $3,000 and you ALSO record the customer's $3,500 gross payment as revenue, you have double-counted. The MoR already invoiced the customer. _(Common mistakes)_ - **3. Missing the VAT obligation** — When using a payment processor (not MoR), YOU are responsible for collecting and remitting VAT/sales tax. When using an MoR, they handle it. Confusing the two creates VAT compliance failures. _(Common mistakes)_ - **4. Treating inter-account transfers as income** — Moving money from PayPal to your bank account is NOT income. The income occurred when the customer paid. The transfer is just a balance movement. _(Common mistakes)_ - **5. Ignoring FX gains/losses** — When you invoice in USD but receive in EUR (via Wise, PayPal, etc.), the exchange rate difference between invoice date and settlement date creates a taxable FX gain or deductible FX loss. This must be recorded. _(Common mistakes)_ - **6. Not reconciling to processor reports** — Bank statements alone are insufficient for correct payment processor accounting. You MUST obtain and reconcile against the processor's own transaction reports (Stripe dashboard, PayPal activity download, etc.). _(Common mistakes)_ ## Disclaimer This file provides general guidance for classifying payment processor transactions. Processing fees, payout schedules, and MoR arrangements change frequently. Always verify against the processor's actual reports and invoices. This is not tax advice. A qualified professional should review all classifications before filing. ## Disclaimer This skill and its outputs are provided for informational and computational purposes only and do not constitute tax, legal, or financial advice. Open Accountants and its contributors accept no liability for any errors, omissions, or outcomes arising from the use of this skill. All outputs must be reviewed and signed off by a qualified professional (such as a CPA, EA, tax attorney, or equivalent licensed practitioner in your jurisdiction) before filing or acting upon. The most up-to-date, verified version of this skill is maintained at [openaccountants.com](https://openaccountants.com). Log in to access the latest version, request a professional review from a licensed accountant, and track updates as tax law changes.