Invoices.
In your name, not ours.
The platform already carries the order, the logistics and the identity of whoever gave the sample. That is everything an invoice is made of (so it can carry the invoice too, at no additional cost, and issue it under the name of whoever is actually owed). The supplier stays the supplier. The invoice simply writes itself.
Issued in the name
of whoever is owed.
The laboratory invoices the practice. The practice invoices the patient. Neither of them writes anything, and neither of them is invoiced by a company their customer has never heard of. What changes is the labour, not the legal relationship (and that distinction is the whole design).
Small channel invoices are the ones nobody wants to administer: too many, too small, and each needing a client on file before it can be raised at all. Being generated from an order that already exists is what makes them free to produce rather than expensive to chase.
The basis for issuing in a supplier’s name, for laboratories →
It writes itself.
Then it stays provable.
The document assembles from the order (under the supplier&rsquo);s own details, their VAT identifier, their number range. Then it becomes a sealed structured file, and that file is the record that has to survive.
The line items are drawn as bars rather than text on purpose. A page like this has no business showing a realistic invoice with plausible clinical detail on it, even invented (what matters is the shape of the document and where it goes, not what any line of it says).
A record first.
Money about it, after.
The moment an invoice seals, it stands in the Pulse ledger (before any money moves, visible to whoever it belongs to). When settlement runs, it references the record; it never replaces it. Paid or unpaid is a fact about the invoice, and the invoice outlives the fact.
The ledger’s own screen.
Each invoice is a row under the name it was issued in: sealed ones standing as records, the one being issued sealing as you watch, and settlement referencing (never replacing) the row it pays.
It arrives where their system reads.
A PDF on an email is a picture somebody still has to type in. A sealed invoice here is converted (automatically, per counterparty and per country) into the structured format the recipient’s own system expects, delivered into that system through licensed e-invoicing, and confirmed back. One connection carries the compliance, the conversion and the delivery; nobody maintains format lists.
The invoice is the record.
Not the way you get paid.
The obvious design collapses invoicing into payments: raise the document when the money moves, and treat it as a receipt. That is wrong in a way that only shows up later. An invoice is a fiscal record of a supply that happened, and it is owed to the tax position of whoever made that supply (produced and retained whether or not anybody ever pays it, and whether or not the money is collected somewhere else entirely).
That is why these are two modules and not one, and why the clock runs from the supply rather than from the payment.
No project. No deadline.
Germany’s B2B e-invoicing mandate arrives in stages, and what a laboratory faces alone is building structured e-invoicing in-house, retiring paper and PDF, arranging compliant archiving, and testing it before a fixed date (for a channel of small invoices it did not want to administer in the first place). Every invoice on this channel is born compliant. Nothing to build, and no date to be ready by.
One document.
Three people who never wrote it.
A practitioner never meets it. Invoicing waits on the result, and the person who took the sample has long since moved on.
Invoices among the modules → · Payments, which waits on this →
Good to know.
Whose invoice is it, legally?
The supplier’s. The laboratory remains the principal and the invoicing party for its analysis, and the practice for the medical act. We never become the seller of the test (what the platform changes is who does the work of producing the document, not who is responsible for it).
Why are Invoices and Payments two modules?
Because an invoice is a record of a supply, not a record of a payment. It is owed to the tax position of whoever made the supply and is produced and retained whether or not anyone pays it (so it cannot be generated by a payment event without becoming wrong whenever money and supply do not line up).
What format is the invoice?
A structured, machine-readable file to EN 16931, the European standard. That sealed file is the legal original. A PDF can be produced alongside it for anyone who wants to read one, but it is a courtesy rather than the document.
What about VAT?
The invoice carries the supplier’s own VAT identifier and their treatment of the supply, because they remain the supplier. What that means in any particular market is confirmed by written opinion for that market rather than asserted here (it turns on the panel and the jurisdiction, not on the structure).
Does the patient get one?
Yes, in Flow, from their own practice and in the practice’s name.
Why does it wait on the result?
An invoice cannot be raised for a test nobody knows completed. That is a technical fact rather than a commercial gate, and it is why Invoices sits after Results in the sequence and Payments sits after it.
Does this need an integration?
Yes (it is one of the five modules that arrive with the single connection between a laboratory&rsquo);s systems and ours. Four modules run with nothing installed at all.
The invoice writes itself. In your name.
Talk to us about a channel of small invoices that produces itself, arrives compliant, and stays provable for as long as it has to.