The disclosure handoff and accessing allocation data

Once an allocation is confirmed, the disclosure handoff turns it into one consolidated dataset per country. That dataset is a file your transparency process can take as it stands. Where a transparency destination is connected, it is also a delivery to that destination. This guide covers the per-country handoff, downloading it, the sync status beside it, and where the allocation data is read on the event record afterwards. Running and correcting an allocation covers running and confirming the allocation itself.

Handing off to your transparency systems

Once the allocation is confirmed, the module prepares one consolidated handoff per country. It follows the disclosure basis your transparency process defined during implementation. Each country's handoff is downloadable as a file. Where a transparency destination is connected, it is delivered to that destination over integration as well, alongside the view your finance team works from. The consolidated per-country handoff has been available since the 2025.12 release, two releases after allocation itself.

Connecting your transparency systems is an implementation step of its own. It comes after the transfer-of-value setup described in Setting up transfer of value and cost category mapping. So an organization normally confirms its first allocations before a destination is connected (see How to plan your Onomi 360 implementation).

While no destination is connected, the Handoff tab shows the per-country breakdown and its downloads, with no delivery-status line. Reopen stays available to the event's finance owner, because nothing has been delivered. An organization in that position works from the downloaded country files, a complete route to a disclosure rather than a stopgap.

Delivery is triggered by confirmation, so connecting a destination does not deliver an allocation that was confirmed before the connection. The event's finance owner delivers such an allocation by reopening it and confirming it again, which delivers it to the connected destinations. From that point the first delivery withdraws Reopen on the normal rule, and any later correction runs through Correct allocation (see Running and correcting an allocation). Nothing announces which allocations are in this state, so work the events you confirmed before the connection from the list your implementation keeps.

Each handoff contains everything the downstream process needs to consume a finished record:

• The recipient each row is filed on. Each is identified by their resolved master identity reference and the identifiers it resolved to, the same ones the Review tab lists (Veeva ID, OneKey, NPI). Confirmation is blocked while any line rests on an unresolved identity, so every row that reaches a destination names a recipient your HCP master already holds.
• The allocated per-HCP amounts in the three cost categories, in the event currency. Currency conversion happens downstream, in your transparency process.
• The HCP's country of practice and the event country on every row. The per-country consolidation follows the disclosure basis your transparency process defines.
• The attendance record behind each amount, captured and reported per attendee, with show and no-show states.
• The audit trail: the cost lines each amount came from, who confirmed the allocation and when, and, for a correction, the handoff version it corrects.

Classification labels do not shape what a handoff contains. The handoff runs as a system integration under the organization's configured scope and is not subject to per-recipient classification exclusion, so a classification rule cannot silently drop HCP rows from a disclosure dataset.

To read a handoff, take the file, and check its status:

1. In the Transfer of value module, open the Handoff tab. It shows one handoff per country. Each carries the number of HCPs it consolidates and the totals in the three cost categories, so the disclosable population of the event reads per country at a glance. A line beneath the handoffs states how much of the event's population they cover. The unattributed remainder is shown as a held line outside every country handoff, because it is not part of any of them.

   

2. Download the country file where your transparency process works from a file, or where a third-party submission platform takes one. Select Download on the country and choose XLSX or CSV. The file carries that country's rows as the contents list above describes them. The module produces the per-event, per-country table your finance and transparency teams work from, rather than anyone assembling it by hand. The download is available whatever the sync chip reads, and it is available with no destination connected at all.
3. Check the chip on each country. It reads Synced, with the timestamp of the sync, once the country's handoff has been taken by your connected destinations. It reads Not synced, with the timestamp of the last attempt, while one of them has not taken it. The compact delivery-status line beside the country totals names each connected destination and what it has taken. So what a country's state rests on is one read. Nothing is lost while a country reads Not synced. The confirmed allocation and its handoff stay on the event record, and the file stays downloadable and complete. A later delivery carries the same version rather than building a new one.

Country disclosure filings are generated downstream in your transparency systems, never in Onomi.

Note: The handoff boundary is deliberate. Publication belongs in the transparency systems your organization has validated. The module's job is to deliver structured, allocated cost and attendee data, as a file or over integration. The filing step then consumes a finished record instead of assembling one.

Accessing the allocation data

The confirmed allocation lives on the event record, next to the budget it was allocated from and the attendees it was allocated to. The finance owner reads the per-HCP amounts in the Review tab of the Transfer of value module. The transparency team receives those same amounts through the handoff, in the country file or over the connected destination. One part of the picture stays in the module.

The unattributed remainder is not part of the handoff. So the people who file your disclosures read it on the Review tab before filing. Each entry carries its amount, the cost line it came from, and the reason it was not attributed. An amount lands in the remainder for these reasons:

• The recipient was not recorded present. That is where a no-show's cancellation fee lands.
• No recipient was set on the line.
• The person the cost belongs to was recorded present, and their registrant type is not ToV-relevant.
• The share of a shared line fell to an attendee whose identity is unresolved.
• The line is shared, and no attendee recorded present carries a ToV-relevant registrant type.
• The line was excluded, and the entry carries the recorded reason and the user who excluded it.

That is what tells a filer that a cost of this event sits outside the dataset they file from, and why. The allocation, the budget, and the attendance record sit on the same event record. So an amount can be traced from a disclosure question back to the cost line and the attendee it came from, without leaving the event.

For what this module does and where its boundaries are, see How to manage transfer of value on your events.

* Onomi 360 MeetingsEQ exclusive capabilities.