Network Templates

Whether Tenka gives the SAME number your accountant closed. Switching systems usually requires posting everything twice for a whole month — and that is where many implementations die. Here the platform rebuilds a month that has already closed, with the documents you have already sent, and compares it line by line with the official close. Zero double work, and the answer is the same.

Every compared line has the "See why" button. It opens the postings that make up that value, one by one, with the sentence explaining why each one landed on that DRE line. It is what turns "it is wrong" into "it is wrong because of this": instead of knowing that fixed expenses are three thousand reais off, you see the postings and discover that one of them landed there because its nature has no accounting group.

The month you want to mirror. You can fill it in little by little: what you have already typed comes back filled in on your next visit, because the accountant almost never answers everything in the same conversation.

It is recorded together with the run. Months later, when someone asks where that value came from, the answer is there: typed on screen, taken from the trial balance sent, or checked by the accountant themselves.

Net revenue, contribution margin, EBITDA, EBIT and EBT are CALCULATIONS from the other lines. Asking the accountant for a subtotal is asking for the same number twice — and, worse, it would contaminate the result: five derived lines matching for free would push adherence up without proving any classification, which is exactly what this gate measures.

Each comparison becomes a line in the history. What makes the customer flip the switch is not today's snapshot, it is the sequence: 40% in the first run, 78% in the second, 100% in the fourth. A comparison that overwrote the previous one would erase precisely that proof.

Generates the spreadsheet with two tabs: the DRE side by side and, for each line that still does not match, the postings that make it up with the explanation of each one. Only the divergent lines get detail — detailing all eight would turn the file into a statement of the month and bury the question that matters. Values go as numbers, not text: that way the Excel of whoever opens it applies their country's formatting instead of receiving the Brazilian mask frozen inside the file.

Mirroring the current month compares a half-finished month with a close that does not exist yet: everything would diverge and it would teach you to distrust the result. That is why the current month appears as pending, not as a bad comparison.

This is the most important distinction on the screen. Zero is a number the accountant stated; empty is the absence of a statement. If empty became zero, the whole line would count as a divergence and the result would accuse the system of an error where data is simply missing. That is why there are three situations per line, not two: matches, investigate and pending.

The default is one cent, which covers rounding and nothing more. A percentage tolerance hides exactly the error that matters: half a percent of two million in revenue is ten thousand reais of difference accepted in silence. The value is configurable per company, because tolerance is a conversation between you and your accountant.

If the percentage were weighted by the size of each line, revenue would carry the result on its own and five wrong tax lines would go unnoticed. What is proven here is that the engine CLASSIFIES correctly, not that the total closes by chance.

Even with 100% adherence, the gate is not achieved while there is a line without the accountant's number. Without this rule it would be enough to enter the two lines you already know match — the shortcut that would empty the whole validation.

When a posting has a nature without an accounting group — or no nature at all —, the system treats it as OPERATIONAL by default. It is a reasonable default and a dangerous silence: the value enters the DRE on an assumption, and nothing warns you. That is why the detail begins the explanation of these postings by saying exactly that. Fixing the nature in its record usually makes the line match in the next run.

At the bottom of the detail appears the sum of the listed postings, and it has to equal the value in the "In Tenka" column. If it does not, the screen warns at the top, prominently. In that case the list serves as a clue and not as proof, and it is worth opening a ticket: a detail that does not add up is a platform defect, not a defect in your data.

Depreciation does not come from a financial posting: it is calculated from the Fixed Assets register, dividing the asset's value by its useful life. A divergence there is almost always a useful life or acquisition date different from the one the accountant used. Net income, in turn, is a calculation from the other lines — when they match, it matches too. In both cases the detail explains the origin instead of showing an empty list.

The subject, the body and the entire spreadsheet — labels, headers and the explanations of each posting — go out in the recipient's language. The screen shows which one, next to the address, BEFORE you click. This exists because the opposite mistake produces no error at all: the email would be delivered, the queue would record success, and the accountant outside Brazil would simply not understand what they received. The language comes from the accountant's record; if they do not have one, the language configured for the account applies.

The difference is real and worth understanding before accepting. The most common causes are three: a document for the month that has not been read yet, a nature classified in another group of the cascade, or a legitimate difference in criteria between the management and accounting views (provision, tax accrual period). Fix what can be fixed and run again — each run is recorded.

It lists exactly what is missing, with numbers: how many of the month's outgoing invoices have been read and how many bank accounts have a statement for the period. Without documents, the rebuilt revenue is smaller and the divergence would be the DOCUMENT's, not the system's — and you would conclude that Tenka gets it wrong.

It first looks for a platform user with the Accountant profile linked to this company — that is the good path, because then the email is a real field and the person has a registered language. If none is found, it uses the firm's contact filled in under Settings › Tax regime; since the field there is free text (it can hold a phone number and a website), only what looks like an email address is accepted. In any case you can type another address on the spot, and the screen says where the pre-filled one came from.