P2PTab

Methodology

Last updated October 18, 2026

The buy and sell prices on P2PTab come only from Binance P2P advertisers with at least 30 completed orders and a 95% completion rate in the last 30 days, and only from ads that take the order size shown; they are checked every ten minutes. The tax tools work from the values in your own file and mark anything they can't value as unknown.

How the USDT P2P rates are worked out

Every ten minutes we look at the public Binance P2P ads for USDT in each currency we cover, for buying and for selling: once across all payment methods and once for each payment method listed on the page. Binance shows the 20 best-priced ads for each search, and on some days all 20 come from accounts with little history, so we combine the ads from all of a currency's searches, counting each ad once. A reliable seller who only shows up in, say, the Easypaisa search still counts.

Reliable advertisers. Only ads from advertisers with at least 30 completed orders and a completion rate of 95% or more over the last 30 days count towards the prices. When ads from less established accounts offer more than the best reliable buyer, the page says how many there are rather than hiding them.

Prices far from the rest. An account with a good record can still post an offer that is too good to be true. We look at the 20 best-priced ads on each side of a USDT market, whatever the payment method, as Binance lists them without a payment filter. Once at least five of them come from reliable advertisers, a buyer offering more than 5% above the middle of those reliable buyers' prices, or a seller asking more than 5% below the middle of those reliable sellers' prices, is left out of the prices as well, and the page says so with that offer's price. Prices for other coins spread wider around the middle, so there every reliable ad counts.

Order limits. Every ad sets a minimum and a maximum order, and the advertiser may have less USDT left than the maximum. An ad takes an order when the order is at least its minimum and no more than its maximum or what is left, whichever is smaller. Binance gives these limits in USDT, cut to the cent: an ad whose minimum is Rs 70,000 at Rs 283.67 shows 246.76 USDT. The pages turn such a limit back into the round amount it stands for, and an amount you enter in local currency is turned into USDT at each ad's own price.

Buy from and sell up to. "Buy from" is the lowest price per USDT among reliable ads that take an order of the market's usual size: 100 USDT on the Pakistan, Kenya, Tanzania, Uganda, Sri Lanka, India, Oman, Zambia and The Gambia pages, 1,000 USDT (1000U) on the Chinese yuan page. "Sell up to" is the highest price a reliable buyer pays for an order of that size. Under each, the page also gives the cheapest reliable seller (or best reliable buyer) at any order size, with the orders that ad takes, because the cheapest ad often takes only large or only small orders.

Decimals. A price shows as many decimals as Binance quotes in that currency, two for most of them. A price of 100,000 or more, such as one bitcoin in rupees, is shown in whole units.

Middle of the 3 best. The middle one of the best prices from the first three different advertisers that take the order.

Other amounts. The table by order size, the price by payment method and the calculator work the same way for each amount: the best price among reliable ads that take it, and how many different reliable advertisers take it.

When no ad takes an order. If no reliable ad among the cheapest ones (or, when you sell, the best-paying ones) takes an order of that size, the page says so and gives the price the other ads start from. Because Binance shows the 20 best-priced ads, every other ad asks at least as much as the 20th, or when you sell pays at most as much. When a search returns fewer than 20 ads, those are all the ads there are, so no such figure is given. An order larger than any single ad takes is worked out as several orders, taking the best-priced ads in turn.

3+ sellers or buyers. How much of the time (prices are checked every 10 minutes) at least three different reliable advertisers took an order of that size.

Yesterday and the hour of the day. The "yesterday" table and the figures by hour follow the market's own clock (Pakistan time on the Pakistani rupee page, Beijing time on the yuan page). The yesterday average only counts the times a reliable ad took the order, and the table says how much of the day that was. Day and month pages use UTC days.

How the daily and monthly history is calculated

A day counts once we have prices for at least 100 of its 144 ten-minute checks. Days run on UTC time. Each month page uses only those full days:

  • For each day: the average, lowest and last best buy price, the average and last best sell price, and that day's US dollar rate.
  • For the month: the average of the daily averages, the cheapest and dearest days, and each payment method's average over the month.
  • By order size: the average best price for 100 and 1,000 USDT orders, and how often three or more reliable advertisers took them.

The day pages behind a month show the opening, highest, lowest and closing price for each payment method that day.

When a payment method has few sellers

Every payment method we follow has its own page. When fewer than five reliable sellers' ads accepted it on average over the last seven days, that page says so and points you to the other methods, because one new or departing ad can move its price a lot.

Where the US dollar rate comes from

The US dollar rate next to the P2P prices is the market rate for each currency from ExchangeRate-API, updated once a day. The percentage next to a P2P price is simply how far it sits above or below that rate.

How the CSV converter reads your exchange file

The converter knows the export files of Binance, Coinbase and Kraken: which columns each one has, how it writes dates, and what each transaction type means. When you open a file, it looks at the first 30 lines for column names it recognizes. If it doesn't recognize the file, nothing is converted and you can send us the column names (only the names) so we can add it.

Every line becomes one of seven kinds: buy, sell, trade, deposit, withdrawal, income or fee. Amounts are worked out to the last digit, so nothing is lost to rounding.

Lines the converter doesn't understand are listed as skipped, with the line number and the reason. Lines that don't add up, such as several trades with the same timestamp, are listed as errors and left out instead of being paired by guesswork.

Which exchange files are checked against a real export

Each exchange file carries one of two labels:

  • Based on help pages and sample files: the columns come from the exchange's help pages or, where the exchange doesn't list them (Binance doesn't), from sample files used by open-source tax tools. Sample files with those columns convert correctly, but no real export from that exchange has been run through the converter, so check the first rows after you import.
  • Checked against a real export: a real, anonymized file from that exchange converts correctly, and the date of that check is shown.

Which currency the calculator uses

Values are taken in the currency the file states them in: a UK Coinbase account reports pounds, a German one euros. When a file mixes currencies, the calculator uses the one most lines are in, and anything in another currency counts as unknown rather than being converted at a rate we'd have to pick.

  • Cost of a purchase is what the file says you paid, plus any fee paid in that currency.
  • Proceeds of a sale are what the file says you received, minus any fee paid in that currency.

When you choose a country (Australia, India, South Africa or New Zealand), the calculator works in that country's currency instead. A trade against a US dollar stablecoin such as USDT or USDC is valued at 1 US dollar per coin, and US dollar values are converted at the European Central Bank's reference rate for that day (the last published day, for weekends and holidays). These values are marked as estimates in the results. The ECB doesn't publish Pakistani rupee or Kenyan shilling rates, so the Pakistan and Kenya pages work in the file's own currency.

FIFO, LIFO, HIFO, average cost and UK share pooling: how each is calculated

Countries match sales to purchases differently, so the calculator runs five methods side by side.

FIFO, LIFO and HIFO match individual purchases: the oldest, the newest or the most expensive per coin. Purchases are matched per account, so coins bought on one exchange are only matched against sales on the same exchange. For these methods the gain is also split by how long the coins were held (one year or less, more than one year, counting from the day after the purchase), because several countries treat longer-held coins differently.

Average cost keeps one running total per coin across every account in the file. Each purchase adds its quantity and cost, and each sale takes cost at the running average. Canada's adjusted cost base works this way; we don't apply Canada's superficial loss rule.

UK share pooling follows the order HMRC sets out for cryptoassets. A sale is matched first with the same coin bought on the same day, then with the same coin bought in the following 30 days (earliest first), and only then with the Section 104 pool at its average cost. We count days in UTC; HMRC counts them in UK time, which can move a trade made just after midnight.

Which method applies to you is a question for the tax rules where you file. The country pages set the calculator to the methods each country accepts.

How fees paid in BNB or other coins are treated

Fees paid in a coin (for example BNB) are removed from your holdings with zero proceeds. Some tax authorities and advisers treat each such fee as a small sale instead; if that matters for your return, raise it with them.

Why some values show as unknown

Crypto-to-crypto trades, income and deposits often come without a value in the file's currency. Apart from the stablecoin trades described above when you pick a country, we don't estimate these. They appear as "unknown" in the results, totals only include the matches where both cost and proceeds are known, and the number of matches with an unknown value is always shown next to the totals.

Sources