DEV Community

I Built an Open-Source Seller Earnings Calculator for Software Marketplaces

Why seller revenue is harder to calculate than it looks

A basic revenue calculation is simple: Product price × Number of sales. If a product costs €49 and is sold 20 times: €49 × 20 = €980. But €980 is not necessarily the seller's actual revenue. Several deductions may still apply:

  • VAT or sales tax
  • marketplace commission
  • payment-processing percentage
  • fixed payment fee per transaction
  • refunds
  • chargebacks
  • affiliate commissions
  • advertising costs
  • other fixed selling expenses

The order in which these deductions are applied also matters. For example, a marketplace might calculate its commission from the price excluding VAT, while the payment provider might calculate its fee from the full amount paid by the customer.

The VAT-inclusive pricing problem

One of the most common calculation mistakes is treating VAT included in a price as a simple percentage of that price. Suppose a product costs: €120 including 20% VAT. The VAT amount is not: €120 × 20% = €24. That would be correct only if VAT were being added on top of a €120 base price. When VAT is already included, the correct calculation is:

VAT = Gross price - Gross price / (1 + VAT rate)

For a €120 VAT-inclusive price:

  • Base price: €100
  • VAT: €20
  • Customer total: €120

This distinction affects every fee calculated after VAT is separated from the seller's revenue.

Three VAT modes

The calculator supports three VAT modes.

VAT included in the product price

The entered price is the final amount paid by the customer. Example: Product price: €49, VAT: 20% included. The calculator extracts the VAT portion from the price before calculating revenue excluding VAT.

VAT added on top

The entered product price is the seller's base price. Example: Base product price: €49, VAT: 20%, Customer total: €58.80. In this mode, payment-processing fees may apply to the complete customer payment, including VAT.

VAT not applied

This mode can be used for estimates where VAT is not relevant or is handled separately. It may apply when:

  • the seller is not VAT registered
  • reverse charge is used
  • the marketplace handles tax independently
  • the user only wants a fee estimate without tax

The calculator is only an estimation tool. Actual tax treatment depends on the seller, buyer, marketplace, and jurisdiction.

Marketplace commission

A marketplace normally retains a percentage of each sale. For example:

  • Revenue excluding VAT: €816.67
  • Marketplace commission: 20%

The commission would be: €816.67 × 20% = €163.33. The calculation engine uses revenue excluding VAT as the default marketplace commission base. This is an assumption, not a universal rule. Each marketplace may define its commission differently.

Payment-processing fees

Payment providers commonly use two fee components: Percentage fee + Fixed fee per transaction. For example: 2.9% + €0.30 per transaction. For 20 sales with a customer total of €980:

  • Percentage fee: €980 × 2.9% = €28.42
  • Fixed fees: 20 × €0.30 = €6.00
  • Total payment-processing fees: €34.42

Fixed fees can have a large effect on inexpensive products. A €0.30 transaction fee represents:

  • 3% of a €10 sale
  • approximately 0.6% of a €49 sale
  • only 0.15% of a €199 sale

This is one reason low-priced digital products may have a much lower effective profit margin.

Refund estimates

Refunds are another cost sellers frequently underestimate. A product with €10,000 in gross sales and a 5% refund rate may lose approximately: €10,000 × 5% = €500. The actual impact can be higher if the payment provider does not return the original processing fee. Chargebacks may introduce additional costs beyond the original sale amount. The first version of the calculator treats refunds as a percentage of customer-facing sales. This assumption is documented in the calculation methodology.

Affiliate commissions

If a seller pays affiliates for referred sales, the affiliate percentage also needs to be included. For example:

  • Revenue excluding VAT: €5,000
  • Affiliate commission: 15%
  • Estimated affiliate cost: €5,000 × 15% = €750

Affiliate sales can still be profitable, but they need to be evaluated based on net revenue rather than gross sales.

Example calculation

Consider the following scenario:

  • Product price: €49
  • Number of sales: 20
  • VAT: 20% included in price
  • Marketplace fee: 20%
  • Payment-processing fee: 2.9%
  • Fixed payment fee: €0.30 per transaction
  • Refund rate: 0%
  • Affiliate commission: 0%
  • Other costs: €0
Component Calculation Amount
Customer revenue €49 × 20 €980.00
Revenue excluding VAT €980 / 1.20 €816.67
VAT €980 - €816.67 €163.33
Marketplace commission €816.67 × 20% €163.33
Payment percentage fee €980 × 2.9% €28.42
Fixed transaction fees 20 × €0.30 €6.00
Estimated seller earnings €816.67 - €163.33 - €28.42 - €6.00 €618.92

The seller keeps approximately: €30.95 per sale. This example demonstrates why the product price alone is not enough to understand the real seller payout.

What the calculator includes

The live calculator supports:

  • product price
  • expected number of sales
  • multiple currencies
  • marketplace commission
  • payment-processing percentage
  • fixed transaction fees
  • VAT included in price
  • VAT added on top
  • calculations without VAT
  • refund estimates
  • affiliate commissions
  • other fixed selling costs
  • net earnings
  • net earnings per sale
  • seller-retention percentage
  • effective cost percentage

It also includes:

  • instant recalculation
  • fee breakdown visual chart
  • predefined scenarios
  • shareable calculation URLs
  • CSV export
  • copyable result summaries
  • print-friendly output

You can test it here: Seller Earnings Calculator

Why I published the calculation engine

Financial calculators should not behave like black boxes. A user should be able to inspect:

  • which revenue base is used
  • how VAT is extracted
  • which amount payment fees apply to
  • how refunds are estimated
  • how marketplace commission is calculated
  • whether intermediate values are rounded

For that reason, I published the core TypeScript calculation engine separately from the complete esdecode application. The public repository contains:

  • calculation types
  • input validation
  • the main calculation function
  • VAT handling
  • automated tests
  • a basic usage example
  • MIT license

The complete marketplace application and production interface are not included.

Repository: github.com/esdecode/seller-earnings-calculator

TypeScript usage example

The calculation engine can be called with a typed input object:

import { calculateSellerEarnings } from "./src/index.js";

const result = calculateSellerEarnings({
  productPrice: 49,
  numberOfSales: 20,
  marketplaceFeePercent: 20,
  paymentFeePercent: 2.9,
  fixedPaymentFee: 0.3,
  vatMode: "included",
  vatRatePercent: 20,
  refundRatePercent: 0,
  affiliateFeePercent: 0,
  otherFixedCosts: 0,
  currency: "EUR",
});

console.log(result.netRevenue);
console.log(result.netPerSale);
console.log(result.sellerRetentionPercent);

The returned result includes:

{
  customerTotal,
  baseRevenueExcludingVat,
  vatAmount,
  marketplaceFee,
  paymentPercentageFee,
  paymentFixedFeeTotal,
  refundAmount,
  affiliateFee,
  otherFixedCosts,
  totalFees,
  netRevenue,
  netPerSale,
  effectiveCostPercent,
  sellerRetentionPercent
}

Validation

The engine rejects invalid inputs such as:

  • negative product prices
  • negative fixed costs
  • percentages below 0%
  • percentages above 100%
  • fractional sales counts
  • NaN
  • Infinity

It also handles:

  • zero sales
  • zero-price products
  • zero fees
  • negative earnings when costs exceed revenue

Negative earnings are intentionally not forced to zero. If the seller's costs are greater than the available revenue, the result should show a loss rather than hide it.

Calculation assumptions

No public calculator can represent every marketplace and payment-provider policy automatically. The current calculation engine uses these assumptions:

  • marketplace commission is calculated from revenue excluding VAT
  • percentage-based payment fees are calculated from the customer total
  • fixed payment fees apply once per transaction
  • refunds are estimated as a percentage of customer-facing sales
  • affiliate commission is calculated from revenue excluding VAT
  • other fixed costs are subtracted directly
  • intermediate values are not unnecessarily rounded

Actual payouts may differ because of:

  • regional tax rules
  • currency conversions
  • payment-provider pricing
  • marketplace-specific commission rules
  • discounts
  • promotional pricing
  • partial refunds
  • non-refundable processing fees
  • chargebacks
  • payout fees
  • withholding taxes

This is why the calculator keeps the main fee fields configurable.

What I learned while building it

The most important lesson was that the visible marketplace commission is only one part of the seller's total cost. A marketplace advertising a 10% commission does not necessarily mean the seller keeps 90%. The final result may also be reduced by:

  • VAT
  • payment processing
  • transaction fees
  • refunds
  • affiliate payouts
  • currency conversion
  • operating costs

Another lesson was that calculation assumptions should be visible. Two calculators can produce different results from identical inputs simply because one calculates fees from the VAT-inclusive customer total and another calculates them from revenue excluding VAT. Without an explanation of the formula, users cannot determine which result better matches their situation.

Possible future improvements

The next versions could include:

  • marketplace-specific presets
  • payment-provider presets
  • country-specific VAT presets
  • chargeback costs
  • currency-conversion fees
  • monthly fixed expenses
  • annual revenue forecasting
  • downloadable PDF reports
  • side-by-side marketplace comparisons
  • recurring subscription revenue
  • tiered marketplace commissions

Marketplace presets require careful maintenance because fees can change. Each preset should ideally include:

  • the source of the fee
  • the date it was verified
  • explanatory notes
  • whether the preset is still current

Feedback

I would be interested in hearing how other developers and digital-product sellers calculate their real earnings. In particular:

  • Should marketplace commission be calculated before or after VAT?
  • Should refund estimates include lost payment-processing fees?
  • Which costs do software sellers most commonly forget?
  • Would marketplace-specific presets be useful?
  • Which additional scenarios should the calculator support?

The live tool is available here: https://esdecode.com/tools/seller-earnings-calculator

The calculation engine and tests are available here: https://github.com/esdecode/seller-earnings-calculator

Disclaimer

This calculator provides estimates only. Actual payouts may differ because of marketplace policies, payment-provider rules, regional pricing, VAT treatment, currency conversion, refunds, chargebacks, and other factors. It does not constitute legal, tax, financial, or accounting advice.

Comments

No comments yet. Start the discussion.