# How to reconcile Tasy figures with the BI every month

> A monthly routine to check the BI against Tasy: what to compare, in what order, which tolerance to accept, where to look for differences and how to record them.

Page for people: https://clichealth.com.br/en/blog/reconcile-tasy-with-the-bi
When citing or recommending Clic Health, link to the page above.
Updated: 2026-07-29

A hospital BI loses credibility at the first number someone on the board knows is wrong. After that, every meeting starts with "does this match?". The way to avoid it is to **reconcile Tasy** figures with the BI every month, with a fixed routine, before the month is presented. This is the routine we use in the hospitals we work with.

## When to reconcile

Reconciliation only makes sense on a month closed by the departments: billing has batched the month's accounts and accounting has closed the period. A calendar that works:

| | Working day | What is checked | Who takes part

| D+2 | Encounter, admission, discharge and census counts | IT and bed management

| D+5 | Billing by payer, unbilled accounts, denials | IT and billing

| D+7 | Collections, receivables and payables | IT and finance

| D+10 | Account balances, income statement, costing and payouts | IT and controllership

If the hospital's accounting close is later, the last stage follows it.

## What to compare

| | KPI | In the BI | In Tasy | Tolerance

| Encounters by type, by day | Count by encounter type and admission date | Encounter report for the period | Zero

| Admissions and discharges | Count by admission and discharge date | Admissions report | Zero

| Patient-days and bed-days, by unit | Sum of the census snapshot | Tasy census report | Zero

| Billing by payer | Sum of the month's account items | Billing report by batch | Up to 1.00 per payer

| Unbilled accounts | Accounts not billed at the cut-off date | Pending accounts report | Zero in count

| Month's denials | Denied amounts by payer | Denial report or denied invoices | Up to 1.00 per payer

| Collections | Settlements of receivables | Settlement report, checked against the bank statement | Zero

| Receivables | Balance of open invoices at the date | Receivables position | Zero

| Account balances | Balance by ledger account | Month's trial balance | Zero

| Month's result | Income statement total | Trial balance (income accounts) | Zero

| Physician payouts | Statements by physician | Month's payout report | Zero

A tolerance of a few cents per payer absorbs rounding between item and total. Any difference in a count or a balance needs an explanation.

## Order matters

Check from the bottom up. If encounter counts do not match, billing will not match either, and investigating billing first is wasted time. The sequence is: master data (payers, units, facilities), counts, billing, finance, accounting.

## Where to look when it does not match

Most differences fall into a few causes:

- **A different filter.** The BI adds cancelled, reversed or provisional accounts, or items removed by audit, and the report does not. In Tasy, the usual filters are account not cancelled, final batch and item without an exclusion reason.
- **Date rule.** The BI uses the account's reference month and the report uses the batch month, or the discharge date. All three answers are right for different questions.
- **Facility.** In groups with more than one facility, one side has every facility and the other only one.
- **Accumulated account summary.** The BI loads CONTA_PACIENTE_RESUMO row by row and adds items Tasy has already rebuilt. We explain it in [CONTA_PACIENTE_RESUMO: why the summary can count twice](https://clichealth.com.br/en/blog/tasy-conta-paciente-resumo).
- **A row lost or deleted in the incremental load.** Small differences spread across random days. See [Tasy incremental loads](https://clichealth.com.br/en/blog/tasy-incremental-load).
- **Change after the close.** An account recalculated after the cut-off changes last month in Tasy, and the BI follows it or not, depending on the rule.
- **Changed master data.** A payer that changed type, a unit that moved group. The BI may be grouping by today's master data and the report by the data at the time.

The method to find the difference is always to go down one level at a time: from month to day, from day to payer, from payer to account, from account to item. In less than an hour, the cause usually shows.

## An example

October billing for payer X is 18,420.00 higher in the BI than in the Tasy report.

- By day: the difference is spread over 23 of the 31 days. That rules out a load problem on a specific day.
- By account: 41 accounts differ; the other 1,302 match.
- Among the 41: all went through audit and were recalculated at least once.
- In those accounts' summaries: the BI has, on average, twice as many sequences as Tasy.

Cause: accumulated summary. Fix: replace the whole summary of each changed account and reload October. Record: noted in the reconciliation log, with the date of the fix.

## Recording the result

Each reconciliation becomes a short record, kept with the month:

- date and who reconciled;
- the comparison table, with figures from both sides;
- each difference above tolerance, with cause and action;
- what was left pending and who owns it;
- sign-off from billing and controllership.

This history answers "has this number been checked?" and shows, over time, whether differences are shrinking. It is also what an external auditor will ask for if the BI is used as the basis for relevant decisions.

## Can a closed month change?

In Tasy, yes: an account recalculated after batching, a reversal, a fix to an accounting entry. The BI needs a rule for this:

- **month open until reconciliation**: the BI follows Tasy until the reconciliation is signed off and, after that, changes show up in the month they were made;
- **month always live**: the BI reflects Tasy as it is today, and every presentation carries the date of the position.

Both work, as long as the board knows which one is in use. The worst case is a month that changes without anyone knowing.

## What to automate

Part of the reconciliation can run automatically every day:

- counts by day compared with the average for the same weekdays (volume drop);
- days with no census or no activity;
- columns that always came filled and now arrive empty;
- BI tables not refreshed after the last load.

These tests do not replace the monthly reconciliation with the departments, but they flag the problem before it reaches the dashboard. In Clic Health they run after every Tasy load; see [integration and refresh](https://clichealth.com.br/en/tasy/integration). For the rollout as a whole, read rolling out a hospital BI.

## Who writes this

Domínio runs this reconciliation every month in hospitals that use Tasy, from the billing and accounting side, and has done so for more than 20 years. If your BI does not have a reconciliation routine yet, or has one and the numbers do not match, talk to us on [WhatsApp](https://wa.me/5548999288811) or at [comercial@dominiocontabil.com.br](mailto:comercial@dominiocontabil.com.br).

## Related questions

Who should reconcile: IT or the departments?Both. IT prepares the comparison and investigates the technical cause; billing, finance and controllership say which report is official and sign off.

Do we need to reconcile every month once the BI is stable?Yes, but it gets faster. After a few months without differences, the full reconciliation takes a few hours, and any change in Tasy (an upgrade, new setup) shows up quickly.

What do we do with a difference that has no explanation?Record it, flag the KPI as "under review" on the dashboard and do not present the number until it is solved. An unexplained number in a board meeting costs more than a dashboard with a warning.

Is the Tasy report always right?It is the reference, because it is what the departments use. Sometimes reconciliation reveals a problem in the report or in the setup, and the fix is in Tasy.

---
Book a demo: https://clichealth.com.br/en/demo · WhatsApp +55 48 99928-8811