The new TSD: a game of back and forth
We wasted no time putting the new TSD form — and the process of submitting payment information to the Estonian Tax and Customs Board (Maksu- ja Tolliamet, MTA) — to the test.
Our first impression of manual entry can be summed up in three words: back and forth.
You move between the payment-entry form and the tax calculation summary, checking how the figures change every time you add or correct something.
Two fields in particular caught our attention:
- Gross payment amount (Väljamakse summa (bruto)).
- Amount subject to social tax (Sotsiaalmaksuga maksustatav summa).
It looks like an ordinary salary payment. Yet the accountant still needs to understand why those amounts may differ, which rules apply to the payment and precisely what information the system expects.
Once the details are saved, the MTA system calculates the taxes. If the result is not what you expected, you go back to the source data, amend it and check the calculation again.
Back to payments. Over to taxes. Back to payments again.
Being able to check the result is useful, of course. But is this quite what we had in mind when we heard the word simplification?
Where does manual entry begin?
The new TSD shows payments for the selected month in a single list.
To add a payment, you open a separate form. And immediately, it becomes clear that a single salary figure will not be enough.
You must also identify the recipient, select the identification method, enter an identification code and, where relevant, provide tax-residency information.
That last button is particularly telling: “Save and calculate taxes” (Salvesta ja arvuta maksud).
In other words, the user enters the facts first — and then asks the Tax and Customs Board's system to calculate the taxes.
Every correction now has its own version
Another feature of the new interface caught our eye: the payment version number.
The payment details include a field labelled Väljamakse versioon — “Payment version”. When a record is amended, the system tracks the changes and displays its version number. A single payment can therefore acquire a history of corrections.
There is a sensible reason for this: the system needs to distinguish the original information from later amendments.
Still, from an everyday user's perspective, it feels rather novel. In the past, an accountant corrected a mistake on a return. Now the corrected payment gets its very own version.
Digitalisation has reached the history of our mistakes, too.
The tax authority knows you entered it by hand
There is another revealing detail in the new system.
Payment records show how the information was submitted, under Väljamakse edastamise viis — “Method of submission”. If a payment was entered manually, it is marked “Added manually” (Käsitsi lisatud).
So the Tax and Customs Board records not just the payment, but also how the information reached it.
Perhaps these details will eventually help show how many businesses have moved to automated data submission and how many still file by hand.
90 payment codes: which one is right?
The new reporting process uses a detailed payment-type matrix.
The official MTA spreadsheet applicable from 1 October 2026 contains 90 distinct payment codes across 125 rows describing their conditions of application. The matrix does not include certain payment types covered by the special rules for ship crew members.
Accountants need to classify each payment correctly, because the payment type affects how it is taxed.
Some of the main TSD payment codes
| Code | Type of payment |
|---|---|
| 10 | Employment income under an employment contract |
| 17 | Remuneration under a contract for services or another contract governed by the Law of Obligations Act |
| 21 | Remuneration paid to a member of the management board |
| 24 | Employer-paid sickness benefit within the statutory limits |
| 37 | Employment income subject only to social tax under specific rules |
| 38 | Contract-for-services remuneration subject only to social tax under specific rules |
| 120 | Employment income paid to a non-resident |
| 123 | Contract-for-services remuneration paid to a non-resident |
| 129 | Sickness benefit paid to a non-resident in qualifying circumstances |
| 156 | Management-board remuneration paid to a non-resident |
Additional codes and conditions apply to other categories of income.
For example, code 10 normally covers employment income regardless of whether the employee receives a fixed monthly salary or is paid for the hours worked. Employer-paid sickness benefit within the statutory limits is reported under code 24.
But choosing the right code is not always enough. Tax residency, the type of contract, insurance status and other circumstances may also matter.
And that is where things become interesting.
What do the 125 entries in the matrix mean?
Consider an ordinary payroll calculation.
An employee may or may not contribute to Estonia's second-pillar pension scheme. Their contribution rate might be 2%, 4% or 6%.
They may be receiving an old-age pension, have partial or no work ability, claim tax-free income or have made no application to use the tax-free allowance.
Unemployment insurance, the minimum social-tax liability, payments under service contracts and management-board remuneration all bring further rules and exceptions.
Each situation calls for the relevant rules to be checked. Once you start building payroll software, the number of possible combinations grows alarmingly quickly.
The MTA’s official payment-type matrix contains 125 entries setting out different conditions of application. These are not 125 exhaustive payroll formulas — and certainly not every possible combination of tax circumstances an employer might encounter.
Which raises the bigger question: should every accounting software provider really have to recreate the entire logic of the government's tax calculation system?
So who calculates the taxes now?
This is one of the most interesting changes in the new TSD.
Businesses provide the underlying payment data, while the Estonian Tax and Customs Board uses that information to generate the return and calculate the tax liabilities.
That is a significant change in how the declaration is prepared.
Employers must still calculate salaries correctly, determine deductions and establish the amount actually payable to the employee. Preparing payment information for a tax return, however, is not the same task as calculating the final tax liabilities within the MTA's own system.
Accounting software needs to identify the payment type correctly, assemble the required information and supply it in the specified format.
Some of the calculations that software developers have traditionally implemented themselves are now performed by the MTA as part of TSD processing.
Perhaps this is where the real simplification lies — even if it is not immediately obvious when you are filling in the form by hand.
Can manual entry be avoided?
Yes. The MTA provides several ways to submit payment data: enter it manually, upload a prepared file or send it directly from compatible software.
The new data format for payments is XML based on XBRL GL. This allows accounting systems to produce a structured file containing the required payment information.
The updated e-MTA interface already includes options for importing that information.
With a prepared file, an accountant does not have to re-enter every payment from the payroll records into e-MTA. The file can be uploaded, the processing results and tax calculations checked, and the return then confirmed.
But a valid XML file does not replace an accurate payroll calculation. If the payment amount, date or type is wrong, automation will not fix the underlying mistake by itself.
10 November: the new TSD's first real test
10 November 2026 is the first filing deadline for the new TSD reporting process, covering payments made in October.
Businesses and accountants will now be able to judge how well the updated system works in practice.
Has the amount of manual work gone down? Are error messages clear? Is it easy to correct a payment? And, above all, does the new process actually save time?
The answers will not come from presentations or guidance notes. They will come from everyday use.
Moving towards automated data exchange is undoubtedly the right direction. But digitalisation should make life easier not just for large businesses with integrated accounting systems, but also for small companies that manage their own accounts.
Leave a comment
Comments 0