Paddle, Lemon Squeezy and the Israeli in between: the Merchant of Record guide
Many builders choose to sell through a Merchant of Record - Paddle, Lemon Squeezy and their peers - precisely because of the promise: "we will deal with the taxes of the whole world, you just build." That promise is largely true, but it does not exempt you from the Israeli side - it changes it. And for the better: this structure dramatically simplifies how an Israeli business operates. Let us understand how it works and what exactly is required of you.
What a Merchant of Record is, in an accountant's language
In a Merchant of Record (MoR) structure, the company - Paddle, Lemon Squeezy - is the official seller of your product to the end users: it is the one appearing on the payment page and on the customer's credit card statement, it is the one issuing them an invoice, and it is responsible for collecting and remitting European VAT, American sales tax and every other local tax. You, for your part, sell to the MoR itself the right to distribute the product, and receive periodic payment from it for the sales, net of the fee.
The legal and accounting meaning for you is dramatic in its simplicity: instead of thousands of end customers in dozens of countries, you have one customer - a foreign corporation.
What it does to your Israeli picture
- VAT: your income comes from a transaction with a foreign resident (the MoR company), so it is the natural candidate for the zero rate - subject to the conditions and the documentation. The fact that some of the product's end users may be Israeli is a question examined according to the structure of the agreement; in most standard MoR structures, your side of the transaction is with the foreign corporation. The final classification is made with us on your specific agreement - do not assume on your own.
- Invoices: instead of a document per charge, one periodic reconciliation with the MoR, based on its sales reports. On the order of one document a month instead of hundreds.
- Gross versus net income: precision matters here too. Your income is determined by the reconciliation with the MoR (the consideration due to you under the agreement), and the MoR's fee is treated according to the structure of the agreement. This differs from the Stripe structure - one more reason not to copy working rules between platforms.
- Foreign taxes: almost entirely off your table - that is exactly the MoR's job, and it is real value for anyone selling into dozens of countries.
So what does remain with you? Everything Israeli: opening a dealer file and choosing a track, recording the MoR income in shekels at the relevant rate, VAT filings (yes, you file even when everything is at the zero rate), income tax advances, National Insurance, and the annual return. In other words: the ordinary Israeli routine - simply on one client instead of a thousand.
MoR versus direct processing - the honest comparison
Before the table, the Israeli starting point you must remember: Stripe is not available to an Israeli business - Israel is not on its supported-country list, so the Stripe side of this comparison requires an American entity, with all its costs. For an Israeli business, a MoR is not merely "simpler" - it is the direct route. We expanded on this in the Stripe guide.
| Merchant of Record (Paddle, LS) | Direct processing (Stripe - requires a US entity) | |
|---|---|---|
| Fee | Higher (~5% + a transaction fee) | Lower (roughly ~3%, varies) |
| Global taxes (VAT / sales tax) | On them | On you (with the help of Stripe Tax) |
| Invoices to end users | On them | On you (automated against Israeli software) |
| Your Israeli side | One reconciliation document a month | A document per transaction + VAT separation per customer |
| Control of the payment experience and the data | Lower | Full |
| Particularly suited to | A global product, a team of one, peace of mind | Growing volumes, a need for control, thin fees |
There is no one right answer - there is an answer that is right for your stage. Quite a few builders start with a MoR for the simplicity and move to Stripe - a step that requires an American entity - when the volume genuinely justifies it; others stay with a MoR for years and are happy. Both structures work excellently with an Israeli business - they simply need to be set up correctly from day one.
Setting it up correctly - a short checklist
- A suitable dealer status: usually osek murshe, in order to benefit from the zero rate and from input VAT deduction. The full comparison.
- The MoR agreement in a folder - it is the document your VAT classification rests on. Keep the monthly sales reports as well.
- A monthly recording routine: MoR report, then recording the income in shekels at the rate, then reconciling against what arrived at the bank. Half an hour a month, or zero if we do it.
- Tracking Israeli users: if the product also addresses an Israeli audience, we set a policy together in advance - not in hindsight.
A licensed Israeli CPA (license no. 500125101) accompanying businesses and self-employed clients across Israel - including founders, builders and owners of digital products. Bookkeeping, filings to the authorities, annual reports and personal financial guidance. About Adir →
Official sources
- Paddle - What is a Merchant of Record (definition of the structure)
- Value Added Tax Law - Section 30(a)(5) (Hebrew)
- Israel Tax Authority - VAT filings for dealers (Hebrew)
The information in this guide is general only, current as of August 2026, and does not constitute tax advice or a substitute for professional advice fitted to your business's circumstances. It is a condensed adaptation of our fuller Hebrew guide. For personal advice - talk to us.
Merchant of Record - the questions everyone asks
So I do not need to issue invoices at all to the users who bought the product?
Correct - in a MoR structure the invoice to the end user is issued by Paddle / Lemon Squeezy, because they are the official seller. You document the reconciliation with them: the periodic income according to the reports and the agreement. Note that this is exactly the opposite of Stripe, where every charge requires a document from you - do not mix the two working routines.
Is my Paddle income considered an export even if I have Israeli users?
That is the golden question, and the answer depends on the structure: when the MoR is the seller to the end user, your side of the transaction is with the foreign corporation, which supports an export classification. But there are real nuances here (the structure of the agreement, the nature of the connection to Israel), and this area is reserved for individual examination against Regulation 12a. This is exactly the kind of classification you make once with an accountant, and then sleep well.
Paddle's fee is higher than Stripe's - is it at least recognized as an expense?
The MoR's cost is embedded in the reconciliation with it according to the structure of the agreement - whether as a deducted fee or as the difference between the end price and your consideration. Either way, you are taxed on your real income, not on the end price the user paid. What matters is that the recording is consistent with the reports and the agreement - and that is defined once.
Can I work with both Paddle and Stripe (through a US entity) in parallel?
Absolutely, and many do - for example a MoR for one product and direct processing for another, or a gradual transition. The price is operational: two different recording routines. One dealer file holds all of it without a problem; just make sure the books distinguish between the streams and that each stream is treated by its own rules.
Which is better for a builder just starting out - MoR or Stripe?
When the product is global and you are on your own, a MoR has a strong opening advantage: zero dealing with foreign taxes, one document a month, and a simple Israeli side. When the audience is mainly Israeli, ordinary Israeli processing. And if full control of the payment experience matters to you, that means Stripe, which means an American entity - a step to weigh only with real economic justification. In any case the decision is reversible: your product is not married to a platform.