Building a Crypto Tax Calculator for Romania: The Data Problem

When people hear "crypto tax calculator", the obvious assumption is that the difficult part is the tax formula.

In practice, a large part of the engineering challenge comes before any tax logic is applied.

At The Crypto Support, we are building tools for crypto tax reporting in Romania. One of the first problems we encountered was that transaction data from different exchanges rarely follows the same structure.

A user may think of their activity as simple:

I bought Bitcoin, swapped some of it for ETH, then sold part of it later.

The software sees something very different.

Different exchanges, different data

One exchange may export:

Date
Type
Asset
Amount
Price

Another may use:

Timestamp
Operation
Currency
Quantity
Total
Fee

A third platform may split what the user considers one operation into multiple rows.

Before we can apply any Romania-specific tax logic, all of this data has to be converted into a consistent internal representation.

That is the normalization layer.

A normalized transaction might contain information such as:

• timestamp
• source exchange
• outgoing asset
• incoming asset
• amounts
• fees
• original transaction ID
• value used for later calculations

The important idea is separation.

The tax layer should not care whether a transaction originally came from Binance, Kraken, Coinbase, or another provider.

It should receive a clean transaction object with a predictable structure.

A simplified pipeline

Conceptually, the pipeline looks like this:

Raw exchange data
        ↓
Provider-specific parser
        ↓
Normalized transaction
        ↓
Classification
        ↓
RON valuation
        ↓
Tax calculation
        ↓
Report

This architecture also makes debugging easier.

Imagine the final result looks incorrect.

Instead of asking:

Why is the final number wrong?

we can ask more useful questions:

• Was the CSV parsed incorrectly?
• Was the transaction classified incorrectly?
• Was the RON valuation wrong?
• Was some acquisition information missing?

That traceability matters even more in financial software.

Validation before calculation

A malformed date is not just a formatting issue.

It can affect the value assigned to a transaction.

A duplicated transaction can alter the final calculation.

A missing acquisition record can make a later disposal difficult to interpret correctly.

Useful validation checks include:

• duplicate transaction IDs
• missing timestamps
• unsupported transaction types
• missing amounts
• inconsistent swap records
• missing valuations

Sometimes the correct behavior is not to calculate automatically.

It is to tell the user that a transaction needs review.

Global crypto data, local Romanian rules

The other interesting challenge is that crypto data is global while taxation is local.

An exchange does not export a special "Romania CSV".

A blockchain transaction does not know anything about Romanian tax reporting.

The software first has to answer:

What happened?

Only afterwards can another layer answer:

How should this transaction be interpreted in the Romanian reporting context?

That separation is one of the main architectural principles behind The Crypto Support.

The user experience should remain simple:

Import → Verify → Calculate → Report

But making that workflow simple requires a lot of structure underneath it.

You can read more about why dedicated tooling becomes useful for Romanian crypto users here:

You can read our guide on why dedicated tooling is useful for Romanian crypto users for more details