Running and correcting an allocation

This guide explains how to allocate an event's costs to the individual healthcare professionals (HCPs) who received the value.

It walks through the checks you need to run before you allocate and how a meeting with no workspace is prepared.

It then explains running and confirming the allocation, and correcting one that is already confirmed.

It assumes you have the one-time setup described in Setting up transfer of value and cost category mapping in place.

Before you allocate

Before running the allocation, work through these three checks on the event; each one prevents a downstream correction. The first two look at states the allocation depends on.

You can read both per attendee in Onomi 360, on the Review tab of the event's Transfer of value module.

The Review tab lists every attendee on the event with a registrant type marked ToV-relevant, whatever their attendance state. That listing is what makes the checks below possible.

The tab is where you see those states and whether they are complete.

Changing one of them is workspace work, as each check says, except on a meeting with no workspace (see Meetings with no workspace below).

1. Identity resolution. In Onomi 360, open the event, select the Transfer of value module, and open the Review tab. It lists every attendee with a registrant type marked ToV-relevant.

   On each row you see the resolution state of that profile and the master identifiers it resolved to (Veeva ID, OneKey, NPI). A resolved profile means the amount lands on an established identity.

   For how resolution works today, see Quicker, enriched, CRM-ready registrations with HCP identity resolution and SpotMe/Onomi CongressIQ: Universal lead capture and completing captured lead profiles via real-time identity resolution.

   Resolution against your HCP master is configured with our implementation team. Contact your SpotMe Account Manager if it is not yet set up for your program.

   An open identity is resolved on the attendee's User view page, in the event workspace's Users module. That work needs planner membership of the workspace.

   If your access comes from a strategic meetings management role alone, ask a planner of the workspace to resolve it.

   A meeting with no workspace has no User view page to work from, so that route does not exist. Meetings with no workspace below sets out what applies instead.

   An individual cost line resting on an identity that never resolves blocks confirmation later.

   The block stands until the identity is resolved, or the line is excluded with a recorded reason (see Running the allocation).

   A shared line is not blocked by an unresolved attendee inside its distribution population. That attendee's share is not attributed. It goes to the unattributed remainder with its own reason instead.

   The confirmation block is not the only reason to clear an open identity. An attendee left unresolved at closure is also the row an erasure request later treats differently.

   The attendee row retained on the event record has no master identity reference for its name and its email address to give way to.

   Either way, clear open identities now, so the amounts land on the people they were spent on, not in the remainder.

2. Attendance. The Review tab shows each attendee's attendance state: Show, No-show, or No state recorded when nothing has been recorded for that person yet.

   You see the attendees with no state recorded grouped at the top of the tab, with a count. The completeness check is therefore one look: that count should be zero before you allocate.

   It matters because shared costs are distributed across the attendees recorded as present with a ToV-relevant registrant type (see ToV-relevant registrant types in Setting up transfer of value and cost category mapping).

   An attendee left with no state is outside that distribution, which enlarges the share of everyone else.

   Recording or correcting an attendance state happens on the user list of the event workspace's Users module, which needs planner membership of that workspace.

   On a meeting with no workspace, it happens on the attendee on the event record (see Meetings with no workspace below).

3. Budget actuals. In Onomi 360, open the event's Budget module, and check that the cost lines you need to allocate have amounts in the Actual column.

   Cost lines are created, edited, and settled on the event's Budget module in Onomi 360, as the budget guide documents.

   Every cost of the event is therefore in one place before the allocation uses it. The allocation uses actuals; a cost line without an actual amount has nothing to allocate yet.

   Filling the Actual column is the finance owner's reconciliation pass, described in Reconciliation, invoices, and closing the event.

Note: Consent is not one of these checks, and it appears on no screen in this module. A consent state has never blocked an allocation, whatever its value.

The spend is a financial fact, and the aggregate-disclosure handling a declined consent may call for happens downstream, in your transparency process.

Consent is captured on the registration journey. It is read on the healthcare professional's own record, in the consent field group of its profile details (see HCP registration and validation on your events).

Tip: Run these checks as the event closes, while the team that recorded attendance and costs is still close to the event. The allocation itself then takes minutes.

To verify the event is ready, open the Transfer of value module. The Cost lines tab lists every cost line with an actual amount.

Each line already shows a category and an attribution inherited from the organization's mapping.

Meetings with no workspace

Your organization maps each request category to what approval creates. The categories mapped to record-only get an event record and no workspace, because the meeting itself is the execution.

The self-service small-meeting categories are record-only by default, so this is the highest-volume lane (see How to set up and use meeting requests and approvals).

Those meetings create transfers of value like any other, and they allocate in this module like any other.

Two of the three checks above work differently, because there is no workspace behind them. The role assignment that runs the allocation differs too.

Review the record-only boundaries

• Where the attendees and their identities are. The meeting's attendees are kept on the event record in Onomi 360.

  They do not arrive through registration in a workspace. They appear on the Review tab in the usual way, with their registrant types and the ToV-relevant marking applied.

  Adding attendees to a record-only meeting, below, sets out how they get onto the record and when their identities resolve.

  Resolution runs when the attendee is saved, one attendee at a time. It runs once, at the save that creates the attendee row.

  There is no workspace Users module and no User view page to work from on this lane.

  The event record's attendee list therefore has no separate resolve control, and no control that re-submits a row already saved.

  If a row comes back unresolved, a holder of the finance role with the event in their scope has two documented ways forward.

  The first is to confirm that resolution against your HCP master is configured for your program. If it is not yet set up, contact your SpotMe Account Manager.

  It is the same route as in the identity resolution check in Before you allocate above.

  Configuring it makes resolution run for the attendees saved after it, and it does not re-resolve a row already saved.

  If a row already saved has to be resolved, contact your SpotMe Account Manager, the same route this guide uses for identity-resolution setup.

  The second route is the one the platform itself offers on this lane. It applies when an individual cost line rests on that attendee and blocks confirmation.

  The line is excluded with Exclude line and a recorded reason; that control belongs to the event's finance owner (see Confirming the allocation below).

  The amount then moves into the unattributed remainder. You see the reason and the user who excluded it on the Review tab.

  The dataset your transparency team files from is then short by an amount they can see and account for.

  An attendee left unresolved when the event closes is also the row an erasure request later treats differently.

• Where the attendance state is set. The Show and No-show state is set on the attendee on the event record.

  There is no check-in and no workspace user list to record it on. A holder of the finance role with the event in their scope therefore sets the state.

  On a record-only meeting nobody has workspace planner membership. The finance role is the assignment with this edit on the event record's attendee list (see Role-based access and visibility for internal and external stakeholders).

• Who prepares and runs the allocation. On a record-only meeting, the preparation edits in this module belong to one role assignment: the finance role with the event in its scope.

  Those edits are setting a line's Recipient, changing a line's Transfer of value category or Attribution, and Run allocation itself.

  It is the same role assignment that already has Add attendee and the Show and No-show state there. Nobody has planner membership there.

  On an event that has a workspace, those edits are shared with that workspace's planners (workspace Manager or Editor).

  See Role-based access and visibility for internal and external stakeholders. The same confirmed-state constraint applies here as anywhere else.

  On a line a confirmed allocation has already read, they are closed while that allocation stands (see Correcting a confirmed allocation).

  Confirming the result belongs to the event's finance owner, as it does on any other event.

Add attendees to a record-only meeting

1. In Onomi 360, open the event and select the Attendees section of the event record.

   You see the people recorded for this meeting, each with their registrant type, their identity resolution state, and their attendance state.

2. Select Add attendee and enter the person's name and email address. The control belongs to a holder of the finance role with the event in their scope.

   It is the same role assignment that has the attendance-state edit on this lane, because nobody has workspace planner membership there.

3. Set the Registrant type field. With no registration form to supply it, you choose the type here from your organization's registrant types.

   The type decides whether the person is inside the ToV-relevant population that shared costs distribute across (see ToV-relevant registrant types in Setting up transfer of value and cost category mapping).

   You set the type as you add the attendee. The event record's attendee list has no control for changing it on a row that has been saved.

   The edits on that list are Add attendee and the Show and No-show state (see Role-based access and visibility for internal and external stakeholders).

   Check the type before you select Save, because the row remains inside or outside the disclosable population as entered.

   The type is also what sets the meal-cap divisor. It also decides whether an individual cost line rests on that person or falls to the unattributed remainder.

   If you have to correct a type on a row already saved to the event record, contact your SpotMe Account Manager. It is the same route this guide uses for identity-resolution setup.

4. Select Save. The attendee appears on the list and on the Review tab. Saving is what submits them to the identity resolution service, the same service that resolves registrants and captured leads elsewhere.

   You see the resolution state, and the master identifiers it resolved to, on the attendee and on the Review tab. Resolution runs per attendee as each one is saved.

Attendees are added to a record-only meeting one at a time, and the boundary is deliberate.

There is no self-registration link and no list import on this lane, because these meetings are two, three, or five people, not an audience.

A meeting large enough to need a list import belongs to a request category that creates a workspace.

The same applies to a record-only meeting with an event record that arrived already approved from your CRM, not from a request.

That means one with a request category that maps to record-only on the connector's inbound field mapping. The connector's inbound event mapping brings the event's own attributes and no attendee list.

Those attendees are therefore added here too, one at a time, with Add attendee (see Connecting CRM, HCP identity, and consent).

An arriving record with a category that maps to a workspace instead is not on this lane, and follows the workspace's own registration paths.

Synchronize the meeting record

Record-only meetings run without registration, without check-in, and without an event registration consent capture. A two-person office visit does not need a registration journey to be a compliant record.

No consent wording is presented and no signature is captured at a registration step for these meetings. Any consent status or reference shown for the attendee is synchronized from the customer's consent master. There is no session-level attendance behind the event-level state.

What the record has instead is the attendee list, the attendance state set on it, and the costs on the event's budget.

The meeting record and its attendees sync to your CRM on Meeting record sync, outbound. Connecting CRM, HCP identity, and consent documents that flow.

The record lands as the CRM objects your organization configures, and it includes the attendance state recorded on each attendee.

The state that syncs is the one on the attendee's row. A row with no state set shows No state recorded and still syncs. An unrecorded attendance is not withheld.

That flow runs on the Veeva SpotMe Sync App connector, the documented route for the record-only lane.

If your organization's HCP master is Salesforce, the route for a record-only meeting's record and its attendees on that lane is settled with your SpotMe team during implementation.

The allocation is not part of that sync. It remains on the event record, and it goes to your transparency systems through the handoff described below.

Attendees of a record-only meeting have no platform account, so the in-app Privacy & Legal path is not available to them.

They exercise access and erasure rights through your organization. Work the request with your SpotMe Account Manager.

Running the allocation

1. In Onomi 360, open the event and select the Transfer of value module. The module opens on the Cost lines tab, and you see Open in the header.

   

Preparing the cost lines

1. Review the cost lines. You see each line's description, the Actual amount read from the event budget, the Transfer of value category, the Attribution (Individual or Shared), and, for individual lines, the Recipient.

   The category and attribution are inherited from the organization's category mapping.

2. For each line with attribution Individual, check the Recipient field. It names the attendee the cost belongs to, for example the speaker on an honorarium line or the traveler on an individual flight.

   It also shows the attribution already stored on the cost line.

   Recipient here and Attendee on the line in the Budget module are one stored value with two entry points. A fee line that named its speaker at capture therefore arrives here already attributed.

   What you set here shows on the budget line (see How to use the Budget module). Only what the two pickers offer differs.

   If the recipient is not yet set, select it from the list this field offers.

   It lists the attendees recorded as present with a registrant type marked ToV-relevant, the same population shared costs distribute across. The Attendee picker on the budget line is wider.

   It offers the event's whole attendee list, because a cost is usually committed before anyone has attended.

   The wider picker is how a line legitimately comes to name someone who was not recorded present. Step 4 says what the allocation does with it.

   You can also change a line's Transfer of value category or Attribution if the inherited default does not fit that specific cost; the change applies to that line only.

   These preparation edits belong to two groups: the planners of the event's workspace (workspace Manager or Editor), and holders of the finance role with the event in their scope.

   On a meeting with no workspace, only a holder of the finance role has them, since no planner membership exists there.

   See Meetings with no workspace above, and Role-based access and visibility for internal and external stakeholders.

   They are made while the allocation is open.

   On a line a confirmed allocation has already read, setting the Recipient and changing the Attribution or the Transfer of value category are closed while that allocation stands.

   They open again once the event's finance owner has reopened it. If the handoff has already been delivered, they open again once a correcting version is open (see Correcting a confirmed allocation).

   

   Note: An event with no individual cost lines allocates on its shared lines alone; the Recipient column remains empty and this step is not needed.

The run and the unattributed remainder

1. Select Run allocation. The module attributes each individual line to its recipient. It distributes each shared line in equal shares across the attendees recorded as present with a ToV-relevant registrant type.

   Amounts use the number of decimal places of the event currency, normally two, and if an equal share does not divide exactly, the last row takes the rounding difference.

   The shares of a line therefore add up to its actual amount. The module then opens the Review tab with the result. Two checks run first.

   • If no cost line on the event has an actual amount, the run stops with "There is nothing to allocate. No cost line on this event carries an actual amount."
   • If the event has shared lines but nobody to distribute them across, the run continues and warns: "No attendee recorded present carries a registrant type marked as transfer of value relevant. Shared costs stay in the unattributed remainder." That warning usually means attendance has not been recorded yet, so check it before treating the result as final.

   The unattributed remainder. Every amount the allocation does not attribute to a disclosable recipient remains on the event as the Unattributed remainder. An amount lands there in these cases:

   • An individual line with a recipient who was not recorded present, such as a no-show's cancellation fee.
   • An individual line with no recipient set.
   • A line excluded with a recorded reason.
   • The cost of anyone present with a registrant type that is not ToV-relevant, such as an internal staffer's flight or an agency transfer.
   • The share of a shared line falling to an attendee with an unresolved identity.
   • The whole amount of a shared line with no disclosable population, meaning a shared line on an event where no attendee recorded present has a ToV-relevant registrant type.

     That is the outcome the warning above describes.

   Those costs are not attributed to a person; they remain on the event in the remainder, and nothing is silently distributed.

   When no recipient is set. An individual line with Recipient never set is treated the same way as one naming somebody outside the disclosable population.

   There is nobody to attribute it to. Its amount therefore goes to the remainder with that reason recorded against it, not distributed and not dropped.

   Holding it there is what keeps the review totals complete. An unset recipient is not an unresolved identity, so it does not block confirmation.

   The most disclosure-sensitive line of all, an unnamed speaker fee, is caught by reading the remainder, not by a block.

   Set the recipient and run the allocation again to move the amount onto the person.

   When the recipient was not recorded present. An individual line comes to name someone who was not recorded present in one of two ordinary ways. Neither is an error to fix in the module.

   • Either the cost was booked against a person who then did not come, which is how a cancellation fee or an unused place is captured.

     The Attendee field on the budget line offers the event's whole attendee list, so the money keeps the name it was spent on.

   • Or the attendance record was corrected after the recipient was set, from Show to No-show. The correction leaves an already-attributed line pointing at someone the allocation can no longer disclose to.

   In both cases the amount moves to the remainder. The Review tab names the line, the person it was booked for, and why it is there.

   When a shared line has a stored attendee. A cost line can have both a stored attendee and an attribution of Shared.

   The Attendee field is offered on every budget line, and a line's Attribution can be changed here afterwards.

   The attribution decides what happens. A line with Attribution Shared distributes across the event's present ToV-relevant population, whatever attendee is stored on it.

   The stored value is not read while the attribution is Shared, so no amount is attributed to that person by name.

   The name stays on the budget line as the record of who the cost was booked against.

   If a cost belongs to a subset of the event and the disclosure has to be exact, capture it as individual lines with their own recipients, not as one shared line.

   Note: A shared line always distributes across the whole event's present ToV-relevant population. There is no per-day, per-session, or per-subset distribution population.

   A day-two dinner for 12 people at a three-day congress with 40 present ToV-relevant attendees is divided by 40, not by 12.

Reviewing the result

1. Review the result. On the Review tab you see one row per attendee with a registrant type marked ToV-relevant, whatever their attendance state.

   Each row shows the attendee's name and their attendance state (Show, No-show, or No state recorded).

   It also shows the amount in each of the three cost categories (hospitality, travel and accommodation, and fees for service), and the row total. Only the attendees recorded present have amounts.

   A no-show and an attendee with no state recorded therefore read as zero in every category. Those zeros are the quickest way to spot an attendance record that is not finished.

   Below the attendee rows, the Unattributed remainder row shows every cost the allocation attributed to no disclosable recipient. It shows the cost lines they came from and, for each one, why it stayed there.

   • 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 with an unresolved identity.
   • The line is shared, and no attendee recorded present has a ToV-relevant registrant type.
   • The line was excluded, and the entry shows the recorded reason and the user who excluded it.

   The entries are grouped by reason, so you can read the remainder without opening each line behind it.

   Select a row to expand it: each amount lists the cost lines it came from and the attendee's share of each line.

   

2. Verify the totals. The category totals at the bottom of the Review tab, together with the unattributed remainder, equal the actual amounts of the allocated cost lines.

   Every allocated cost line is therefore either attributed to a disclosable recipient or accounted for in the remainder, with nothing left over and nothing counted twice.

   An excluded line remains inside that sum. Its amount is in the remainder, not dropped from the total.

Confirming the allocation

1. Ask the event's finance owner to review and confirm. The finance owner opens the same Review tab and selects Confirm allocation.

   If you are not the finance owner, you see the tab with the control disabled, beside "Confirm allocation is available to the event's finance owner."

   Confirmation is blocked while any line rests on an unresolved identity.

   The attempt stops with "Confirmation is blocked: 2 cost lines rest on an attendee whose identity is unresolved. Resolve each identity, or exclude the line with a reason." The module lists the affected lines.

   Each one is either resolved (see Before you allocate) or excluded from the allocation with Exclude line, on the line itself.

   On a meeting with no workspace, resolving is not a control on the attendee list. Identity resolution runs once, at the save that creates the attendee row.

   A row already saved is therefore put right on the SpotMe Account Manager route set out in Meetings with no workspace above.

   The alternative the platform offers on this lane is Exclude line. It moves the amount into the unattributed remainder with its recorded reason, on the terms stated below in this step.

   The filed dataset is then short by a visible amount instead of naming a recipient nobody could resolve.

   The block comes from lines resting on an unresolved identity, in the sense of a named recipient who cannot be resolved.

   The blocked case is an individual line with a Recipient the identity resolution service has not resolved.

   A shared line is not blocked by an unresolved attendee inside its distribution population. That attendee's share is not attributed.

   It goes to the unattributed remainder with its own reason. The share is therefore visible on the Review tab before filing, not handed off against an unresolved person.

   Exclude line belongs to the event's finance owner, the same person who confirms the allocation, and it asks for the reason before it excludes anything. An excluded line's amount moves into the unattributed remainder.

   The reason and the user who excluded it are visible on the Review tab, and on the audit trail. That trail is the record of the exclusion.

   The amount remains inside the event's totals, and the dataset your transparency team files from is short by an amount they can see and account for.

   Confirming records the per-HCP amounts on the event record. It adds the name of who confirmed and the confirmation date to the audit trail.

   It sets the module status to Confirmed, and makes the handoff available on the Handoff tab.

Virtual events are allocated the same way. A virtual advisory board or a webinar speaker fee creates transfers of value exactly as a dinner does.

The module allocates them on the same terms: per attendee, from the same budget, into the same review screen.

To verify the allocation is complete, check the module header: you see Confirmed, with the finance owner's name and the confirmation date.

The top of the Review tab shows the same allocation's version number and the date it was confirmed. You can therefore see which version you are reading without opening the audit trail.

Correcting a confirmed allocation

A confirmed allocation is never edited in place, and the same protection extends to the cost lines behind it. While a confirmed allocation stands, three rules apply on a line it has read.

• The Actual amount is closed to hand edits.
• The stored attribution is closed with it, and the line cannot be removed.
• An invoice arriving from your ERP against that line is recorded in the event's Unmatched invoices view, not written over the confirmed figure.

The event's finance owner therefore reopens the allocation first.

If the handoff has already been delivered, Reopen is no longer offered, and the correction follows the versioned Correct allocation path instead (see How to use the Budget module).

The fields a confirmed allocation closes

The attribution is closed on those same terms. It is what the allocation uses to decide whether an amount goes to a named healthcare professional or falls to the unattributed remainder.

The Recipient field in this module and the Attendee field on the cost line in the Budget module are one stored attribution with two entry points.

Neither entry point therefore re-points a line the allocation has read while it stands.

Correcting before and after delivery

What a correction produces depends on whether the handoff has been delivered, and on whether a destination is configured at all.

Delivery is per destination, and an organization can connect up to five. The Handoff tab shows one sync status per country, with a compact delivery-status line beside it naming what each destination has taken.

The correction rule follows the whole set, not each destination separately. Reopen is withdrawn as soon as the handoff has been delivered to any connected destination.

The first Delivered status therefore closes in-place correction for the allocation as a whole, and a country still showing Not synced does not reopen it.

Once a figure is in one transparency system, correcting it in place would leave that system with an amount the record no longer shows.

• Before delivery. The finance owner selects Reopen on the confirmed allocation and enters a reason.

  The module asks for it before it reopens anything: "Reopening returns this allocation to Open. Enter the reason for the correction." The status returns to Open, and the audit trail records who reopened it, when, and the reason.

  Correct the cost lines or the states behind them, run the allocation again, and confirm it.

  The confirmed allocation is then version 2, the reason and both confirmations remain on the trail, and no figure from version 1 is overwritten.

  If you have already exported the event's financial record, export it again.

  Each confirmed version remains on the event record, so the export taken after the correction is the one that matches it (see Reconciliation, invoices, and closing the event).

• After delivery. Reopen is no longer offered, with "This allocation has been delivered to your transparency systems. Corrections are delivered as a new version, marked as correcting the prior handoff." in its place.

  Select Correct allocation instead: the module opens a correcting version, and confirming it produces a new, versioned handoff, explicitly marked as correcting the prior one.

  The correcting version opens in Open, on the same terms a reopen produces.

  The cost lines that allocation read are open for correction again, and an ERP invoice resent against one of them settles there.

  Confirming it returns the allocation to Confirmed with the new handoff behind it.

  The correcting version is delivered to every connected destination, including a destination the original was never delivered to.

  There it supersedes the undelivered original, so no destination is left waiting on a version the record has already replaced.

  The prior handoff is never edited or silently withdrawn, so the downstream systems receive the correction as a record of its own.

  The Handoff tab keeps both versions with their delivery statuses and timestamps. The audit trail has the same detail either way: the reason, who confirmed each version, and the version each one corrects.

  Once the correcting version is confirmed, export the event's financial record again, as you would after a reopening.

  Each confirmed version remains on the event record, so the export taken after the correction is the one that matches it.

  A file exported before the correction states the superseded figures (see Reconciliation, invoices, and closing the event).

• If no destination is configured. An organization without a connected transparency destination uses the confirmed allocation on the event record.

  It has no delivery to divide before from after. Reopen remains available to the event's finance owner.

  What bounds it is the record, not a delivery event.

  Each re-confirmation records a new version of the confirmed allocation, with the reason entered on reopening, the author, and the timestamp. No version is edited or removed.

  The correction trail is therefore the same trail as after a delivery, minus the delivery. Because delivery is triggered by confirmation, connecting a destination later does not deliver these allocations.

  The event's finance owner reopens each one and confirms it again to deliver it.

  The first Delivered status then withdraws Reopen on the rule above, and corrections run through Correct allocation (see The disclosure handoff and accessing allocation data).

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.