Billing that is ready is not billing that has been sent. In between sit 14 payer portals, an XML that will not validate, a login that expired and a window that closes on Friday. TISS — the claims exchange standard every Brazilian hospital and health plan has to use — is only as good as the trip the file makes. The agent covers that trip: it audits the bill before sending, transmits batch by batch, brings the protocol number back and shows you where every submission stands.
TISS is set by the ANS, Brazil's national regulator for private health plans, and the agent works inside it. It audits every claim against what the medical record documents and hands back the line the documentation does not support; rewriting the claim and deciding what goes into a batch when a document is missing stay with the hospital.
The billing team closes the period. From there a second job begins, one nobody calls a job: open each payer's portal, remember the password, upload the file, wait for processing, write the protocol number down in a notebook or a shared spreadsheet, and repeat that fourteen times. When an XML comes back rejected over one required field, nobody can say which claim caused it without opening the file by hand.
The hard part is not producing the bill. It is crossing the distance between finished billing and the payer.
Every page in this section describes the same reference hospital: a mid-to-large network, 28 outpatient specialties, roughly 60,000 outpatients a year, about 2,500 appointment slots offered per week, an official WhatsApp number carrying some 23,000 conversations a month and 14 contracted payers.
That is the size at which transmission stops being one person's task and turns into a calendar bottleneck: the same week every month, the same queue.
Rejection over a technical inconsistency is the most expensive rework in the cycle, because it arrives after everyone thought the work was done; a denial over documentation is worse, because the care has already been delivered. The agent flips the order: before transmitting, it audits the batch against the TISS standard, against that specific payer's rules and against what the medical record documents, and sends only what the documentation supports.
File structure, declared version, required fields, type and length of every field, claim hash, batch sequence. It is the same check the payer's portal would run — except it happens here first, with the file still in your hands.
Two health plans read the same standard differently: one demands an attachment for a given procedure, another refuses a claim without prior authorization, a third uses its own contracted fee schedule. Those rules are registered per payer and run as part of the check.
A file can be technically flawless and still bill a line outside the contract, or a line the documentation does not support: a procedure with no matching clinical note, a supply with no justification, a bed-day with nothing recorded against it. That audit has a page of its own, on coding compliance and reference tables, and its result reaches this step before the batch is assembled — it is what keeps the denial from happening at all.
When something does not hold up, the whole batch is not blocked without explanation. The agent hands back the finding ready to act on, claim by claim: the line, the evidence that is missing, the likely cause and the deadline running, written in plain language — and it says what it cannot fix itself.
The agent also simulates: it runs the validation over the batch under construction as many times as you need, transmitting nothing, so the team can see what is still missing before submission day.
Rejection over a technical inconsistency is the kind you can avoid without negotiating with anyone: it is form, not merit. Checking before you send is what moves the ratio.
A denial on the merits — the payer disagreeing with what was billed — is a different conversation, and it lives on the denials page.
What went back to the team — billing period 09, payer Aurora
| Claim | Line | Reason | Owner | State |
|---|---|---|---|---|
| G-48210 | Outpatient procedure | Code outside this payer's contracted fee schedule | Billing | Blocks the submission |
| G-48257 | Prior authorization | Authorization number missing and required by the contract | Authorizations | Blocks the submission |
| G-48301 | Supporting attachment | This payer requires an attachment for the procedure; the file never arrived | Clinical team | Drops out if unresolved |
| G-48344 | Service date | Date falls outside the period declared in the batch header | Billing | Simple fix |
| 612 claims checked = 608 approved + 4 returned. Of the 4 returned, 2 block the submission and 2 drop out of the batch if they are not resolved by closing. | ||||
Every health plan has its own intake path: a published web service, a file exchange area, a portal with manual upload. What changes from one to the next is the transport and the credential, not your team's work. On the inside, the batch is always assembled, validated and dispatched through the same flow.
The agent reads the closed claims in the billing system through api_get_claims_period and splits them by payer, respecting the claims-per-batch limit each one accepts.
It runs the three layers of checks. What passes moves on; what fails goes back to the team with the line and the reason, and the batch either waits or ships without that claim — a human decides which.
The credential comes from the credential store, never from a file on somebody's machine. The submission is logged with date, time, file size and claim count.
Transmitting is not receiving. The agent returns to the same channel to fetch the protocol number and the processing result, and only treats the batch as delivered once that number comes back.
Payer portal passwords tend to travel by message, spreadsheet and sticky note. On the platform, each payer's access lives in the credential store: held securely, used by the agent at the moment of submission and never displayed back on screen.
Adding a fifteenth payer is not a project: it is a registration. The transmission endpoint comes in as a tool, the payer-specific rules go into validation, and the board starts showing one more column of batches.
The same REST APIs your IT team already maintains become the agent's tools, with no proprietary connector in between. See how integrations work.
There are still fourteen payers. There is now one job for your team.
The protocol number is the payer's receipt that the batch arrived. When it lives in a side spreadsheet, that proof depends on somebody having copied it correctly — and the first time you learn nobody did is when the payer says it never received anything.
After transmitting, the agent returns to the payer's channel, fetches the protocol number for that submission and writes it onto the batch inside the billing system. No copy and paste, no intermediate spreadsheet, no "the protocol is in Claudia's inbox".
api_post_batch_protocol onto the same batch that produced it.It is the same discipline the platform applies to any published document: the number on the screen came from an API call made during that run, not from the model's memory. How the agent builds a document with data by reference.
Checking protocol numbers by hand stops being the routine and becomes the exception: only what the payer did not return automatically still needs human eyes.
Protocol checking goes from nine dedicated posts to three. The six posts no longer needed were retyping and line-by-line checking; what still calls for a person is the case that needs judgement — appeals, authorizations, negotiation.
Doubling the number of claims stops meaning doubling the team that checks them.
A failed transmission is not a rare event: a service goes down, a certificate expires, a processing queue jams on the other end. The design assumes it.
The agent tries again in the following windows instead of hammering the payer's service. Every attempt is logged with the time and the response it received.
If the batch does not close after the planned attempts, the case goes up to the human queue with everything already tried — instead of waiting for someone to open a board by chance.
A resend happens only once the agent has confirmed the earlier submission was not accepted. A duplicated batch at the payer is a bigger headache than a late one.
The question nobody can answer on a Thursday is a simple one: where is each batch right now? The board answers it without opening a payer portal, because the state is updated by the agent itself on every query it makes.
Batches by state — billing period 09
Protocol reconciliation — last 24 hours
| Payer | Batch | Claims | Protocol | State |
|---|---|---|---|---|
| Aurora Norte | 09-0384 | 254 | 2026-09-0000615 | Accepted |
| Serra Azul | 09-0386 | 139 | 2026-09-0000623 | Accepted |
| Sertão Claro | 09-0391 | 203 | 2026-09-0000688 | Partial rejection |
| Vitória | 09-0397 | 376 | 2026-09-0000731 | Under review |
| Rota 12 | 09-0398 | 118 | 2026-09-0000742 | Under review |
| Meridiano | 09-0402 | 441 | — | Awaiting protocol |
| Ipê Self-Funded | 09-0404 | 87 | — | Awaiting protocol |
| Aurora | 09-0409 | 612 | — | Held in validation |
| Claims in the batches listed — 254 + 139 + 203 + 376 + 118 + 441 + 87 + 612 | 2,230 | 2 protocol numbers still outstanding · 1 batch held before submission | ||
A whole billing period on one screen: the batches ready to go out, the ones already transmitted and waiting for a protocol number, the ones under review at the payer and the ones closed with a protocol on file. Below that, the last 24 hours of reconciliation and the submission window next to the earlier scenario.
Nobody opened fourteen portals to build this list. What needs a person is exactly what is flagged amber and red: one batch held in validation and one partial rejection that will turn into an appeal. The eight accepted batches ask nothing of anyone.
Notice what the screen does not show: no clinical patient data. The columns are payer, batch, claim count, protocol number and state. The board tracks the transport of billing, not clinical content — and every change of state is logged with who or what caused it.
The same data feeds the daily panel the Squad publishes and sends. See dashboards and indicators
Worth saying plainly: transmitting sooner does not increase the amount billed. The effect is on the calendar, not on the gross. What changes is when the money lands, how much rework disappears from the path and how predictable the month becomes.
Recovering value itself — denials classified, appeals filed with evidence, contractual deadlines that do not lapse — is the subject of the page next door.
We do not promise higher revenue. Transmitting on time does not make a payer pay more, does not advance a receivable, does not replace contract negotiation and does not turn a denial on the merits into a payment.
What the agent delivers is earlier and with less rework: the batch goes out sooner, goes out correct and goes out tracked.
The agent audits the batch and handles the transport. Deciding what gets billed, to whom and with what argument stays with people — and it should.
The supporting attachment is missing, the clinical note was never closed, the procedure needs an authorization that has not come through. Hold the claim and wait, or send the batch without it and bill later? That is a coordination decision, with consequences for contractual deadlines and for the relationship with the payer. The agent shows the impact of each path; a person chooses.
A submission rule that changed without notice, an attachment demanded that is not in the contract, a processing deadline that blew past. None of that is settled inside an XML. The agent documents what happened — when it sent, what came back, how many times it tried — and hands the material to whoever sits at the table.
When a payer audits, it asks for technical and clinical justification. Most of what it will raise was already audited on this side before the batch went out, and the agent arrives with the batch history, the protocol number, the dates and the attached documents gathered; the answer itself is written by someone who carries professional responsibility for it.
It does not alter claim content to get a batch through validation, does not swap a procedure code, does not decide what is left out of the period and does not speak to a payer on the hospital's behalf outside the contracted transmission channels.
Access controls, credentials and logging are covered in detail on integrations and security.
That payer keeps being served through its portal, and we say so without hedging: where no automated path exists, someone uploads the file by hand. What changes is everything around it. That payer's batch is assembled and validated the same way, appears on the same board and gets the same tracking — and the protocol number, once it is recorded, sits on the same line as the rest.
In practice, the exception stops contaminating the whole process: instead of fourteen manual submissions, you are left with the handful the payer still insists on.
A version change is a platform event, not a project for your hospital. The structural rules of the standard are updated on the Hal-AI side and the agent starts validating against the version in force. What does need a conversation is the calendar: payers migrate at different speeds, and during the transition two versions coexist in the same month.
That is why the version is a property of each payer in the registry, not a global setting. The board shows which version each batch went out under.
The agent retries in the following windows, with spacing, and logs each attempt with the time and the response received. If the deadline gets tight, the case goes up to the human queue with the history ready — including for submission through whatever alternative route that payer accepts.
The batch is not treated as delivered until the protocol number comes back, and the agent never fills in a number it did not receive. We would rather show an empty field than a false record.
No. Correcting claim content is a billing act, with contractual and sometimes clinical consequences. The agent points at the line and the reason, names who resolves it and hands it back to the team. No claim change is ever written by the agent.
What it can do is rebuild the batch once a person has made the correction, revalidate as many times as needed and transmit again — without duplicating the earlier submission.
They live in the platform's credential store, held securely and used by the agent at the moment of submission. They are not displayed back on screen, do not travel by message and do not sit in a file on anyone's machine. Each payer is a declared tool of the agent: whatever was not declared, it cannot reach.
Certificate expiries and password renewals become alerts before closing. The detail is on integrations and security.
We will map out with you how transmission for your billing period would work: what gets validated before it leaves, what goes out on its own, what still passes through a person's hands and what happens to the submission window.