Setting up transfer of value and cost category mapping

Transfer of value (ToV) setup happens once in Onomi 360, and this guide covers it. The cost category mapping classifies every cost line. The ToV-relevant registrant types define who shared costs distribute across. The connection to your transparency systems completes the setup. Do all three before your first allocation, which Running and correcting an allocation covers.

Setting up transfer of value in Onomi 360

Setup happens once, in Onomi 360's Policies area. Every event's allocation then works against the same classification rules, and a per-HCP amount means the same thing across your program.

Cost category mapping

The allocation classifies every cost line into one of three cost categories: hospitality, travel and accommodation, and fees for service. Those three are the platform's own classification of a cost line rather than the disclosure category set of any transparency framework. The framework you file under works in its own categories: the EFPIA disclosure code's itemisation, or the nature-of-payment values US Open Payments requires. Mapping the three onto those categories is a step in your transparency system. The classification is inherited from your organization's budget category hierarchy. Your event budgets are built on that same hierarchy (see Setting up budgets: categories, bands, and policies). To define the mapping:

1. In Onomi 360, open Policies, and select the Transfer of value section.
2. In the Category mapping table, review the two settings each budget category and sub category carries, described below.
3. Adjust the defaults where your transparency process classifies a category differently, and select Save. Every cost line an event creates under a mapped category now inherits its classification. A change to the mapping is recorded with who made it and when, and it applies from the change forward.

The mapping holds one entry per organization-level budget category and sub category. A planner can add an event-specific sub category on a single event budget. A cost line under such a sub category inherits both settings on its parent main category's entry. Those are the Transfer of value category the parent is classified into, and the parent's Default attribution.

So the line reaches the allocation classified as a line under its parent would be, and carrying the same attribution. That attribution is Individual to one named HCP, or Shared across the attendees recorded present whose registrant type is marked ToV-relevant. No cost line reaches the allocation unclassified or without an attribution.

The parent's GL code and its Counts toward the meal cap value pass down on the same rule. Its Sourcing award target does not. Budget capture at request and working the budget during planning documents the inheritance rule.

Transfer of value category
Which of the three cost categories the budget category's costs belong to: hospitality, travel and accommodation, or fees for service.

An entry is never created unset, because a cost line has to reach the allocation classified. A main category added to your organization's hierarchy is created here classified as hospitality. Its Default attribution is Shared, on the rule the next field describes. A sub category added under an existing parent is created carrying its parent's entry, both settings included.

The budget category itself carries no field that says which of the three its costs belong to. So those are starting values rather than a reading of the category. Set the classification here before the first cost line is booked to a category you have just added. Change it when a budget category carries costs your transparency process classifies differently.

Default attribution
Whether costs in this category are, as a rule, Individual or Shared. Individual means the cost belongs to one person, such as a speaker's fee or an individual flight. Shared means the cost belongs to the group, such as the venue invoice, the group transfer, or the catering line.

Every entry is created carrying Default attribution Shared. A sub category carries its parent's value, with the rest of its parent's entry. An administrator sets this field here, and it is not derived from the Transfer of value category. Changing an entry's classification to fees for service does not change its attribution.

That matters most on the categories your speaker fees, honoraria, and consulting costs book to. A line whose attribution is Shared is distributed across the attendees recorded present whose registrant type is marked ToV-relevant, whatever attendee is stored on it. The stored attendee is not read while the attribution is Shared (see Running and correcting an allocation). So set a fee category to Individual here before the first honorarium is booked to it. The planner can set the attribution per cost line before allocating, so choose the default that fits most lines in the category.

Note: The mapping applies across your whole program, and it governs the cost lines captured from the change forward. A cost line captured before the change keeps the classification that was in force when it was captured. So changing the mapping never reclassifies the costs of events that are already reconciled or already disclosed.

A category added to the hierarchy follows the same rule from the other end. The entry it is created with governs the cost lines captured under it from its creation forward. So classifying it here later leaves those earlier lines classified as they were captured.

The same holds when an allocation is reopened. Running it again reads the classification stored on each cost line rather than the mapping as it stands that day. So a reopened allocation reclassifies nothing on its own, and a line whose classification is wrong is corrected on the line itself (see Running and correcting an allocation). Agree the mapping with your transparency team once, and leave event-level variation to the per-line settings described below.

ToV-relevant registrant types

Shared costs distribute only onto participants your transparency process discloses. The registrant-type marking, in the same Transfer of value section, controls who is counted in shared-cost distribution. The standard types the list arrives with cover healthcare professional, internal staff, and agency types, each with a default marking.

1. In the Transfer of value section, open the Registrant types table. It lists your organization's registrant types with a ToV-relevant marking per type.

   Your transparency process may treat transfers of value to public officials as a disclosable class. The EFPIA member codes and the French anti-gift regime are the cases that raise it. Where it does, the type is added on the route described below, settled with your SpotMe team through your Account Manager, and marked ToV-relevant in this same table.

   Until it is, such an attendee is recorded under whichever registrant type they carry. While that type is unmarked, they sit outside the population shared costs distribute across. So an individual line booked to them stays in the Unattributed remainder. The reason recorded is the one Running and correcting an allocation gives for a cost belonging to a person whose registrant type is not ToV-relevant.

2. Adjust the marking where your transparency process differs, and select Save. A change to a marking is recorded with who made it and when. It applies to the allocations run after the change. An allocation already confirmed keeps the population that was in force when it ran. To apply the change to it, reopen the allocation and run it again (see Running and correcting an allocation).

The types in that table are your organization's registrant types, the one list the rest of the platform reads. A registration form offers its registration types from this list. The Registrant type set on an attendee added to a meeting with no workspace comes from the same list (see Meetings with no workspace in Running and correcting an allocation). So the registration type you set on an event and your organization's registrant type are one list under two names, rather than two lists to keep aligned.

The ToV-relevant marking is the only write the table carries, and the list arrives with the standard types the defaults above name. The table holds up to 50 registrant types. Adding a registrant type for your organization, or changing one, is settled with your SpotMe team; please contact your SpotMe Account Manager.

When an allocation runs, shared lines are distributed in equal shares across the attendees recorded as present whose registrant type is marked ToV-relevant. Internal staff and agency attendees stay on the attendance record but receive no share. A shared dinner cost never lands on your own medical team.

Connecting your transparency systems

The handoff delivers the confirmed allocation to the transparency systems that file your country disclosures. Allocation has been available since the 2025.10 release, and the consolidated per-country handoff since the 2025.12 release. Once your destinations are connected, the handoff is available on every event whose allocation is confirmed. The connection is configured with our implementation team; please contact your SpotMe Account Manager to set it up for your program. Two settings are captured during implementation:

Destination
The transparency system, or systems, the handoff delivers to, over integration. Each destination appears in the Handoff tab of every event with its own delivery status.

Disclosure basis
The consolidation rule the handoff follows when it prepares one consolidated handoff per country. Your transparency process defines the basis, and it is captured during implementation. The module consolidates on it.

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

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.