Running and correcting an allocation

This guide covers allocating an event's costs to the individual healthcare professionals (HCPs) who received the value. It covers the checks to run before you allocate, and how a meeting with no workspace is prepared. It also covers running and confirming the allocation, and correcting one that is already confirmed. It assumes the one-time setup described in Setting up transfer of value and cost category mapping is 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 read states the allocation depends on. Both are readable 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 whose registrant type is marked ToV-relevant, whatever their attendance state. That is what makes the checks below performable. The tab is where the completeness of those states is read, as well as the states themselves. 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 whose registrant type is marked ToV-relevant. Each row carries the resolution state of that profile and the master identifiers it resolved to (Veeva ID, OneKey, NPI). A resolved profile means the amount will land 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. Please 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 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. The routes set out in Meetings with no workspace below apply instead.

   An individual cost line resting on an identity that never resolves blocks confirmation later. The block holds 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 is held in 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 reads 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 rather than in the remainder.

2. Attendance. The Review tab shows each attendee's attendance state: Show, No-show, or No state recorded where nothing has been recorded for that person yet. The attendees with no state recorded are grouped at the top of the tab, with a count. So the completeness check is one read: that count should be zero before you allocate.

   It matters because shared costs are distributed across the attendees recorded as present whose registrant type is ToV-relevant (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 everyone else's share. 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 expect to allocate carry amounts in the Actual column. Cost lines are created, edited, and settled on the event's Budget module in Onomi 360, the capture surface the budget guide documents. So every cost of the event is in one place before the allocation reads it. The allocation reads 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 it reads. 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 that carries 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 read differently, because there is no workspace to hold them. So does the grant that runs the allocation.

• Where the attendees and their identities are. The meeting's attendees are held 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. So the event record's attendee list carries no separate resolve control, and no control that re-submits a row already saved.

  Where a row comes back unresolved, two documented routes are open to a holder of the finance role whose scope covers the event. The first is to confirm that resolution against your HCP master is configured for your program. Where it is not yet set up, contact your SpotMe Account Manager. That is the route the identity resolution check in Before you allocate above publishes. Configuring it makes resolution run for the attendees saved after it, and it does not re-resolve a row already saved. Where a row already saved has to be resolved, please contact your SpotMe Account Manager, the same route this guide uses for identity-resolution setup.

  The second route is the one this lane holds in the platform. It applies where an individual cost line rests on that attendee and blocks confirmation. The line is excluded with Exclude line and a recorded reason, which the event's finance owner holds (see step 7 of Running the allocation below). The amount then moves into the unattributed remainder. The reason and the user who excluded it are visible on the Review tab. So the dataset your transparency team files from is 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 reads 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. So a holder of the finance role whose scope covers the event sets the state. On a record-only meeting there is no workspace planner membership for anyone to hold. The finance role is the assignment that carries this write 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, one grant holds the preparation writes in this module. It is a holder of the finance role whose scope covers the event. Those writes are setting a line's Recipient, changing a line's Transfer of value category or Attribution, and Run allocation itself. That is the same grant that already carries Add attendee and the Show and No-show state there. There is no planner membership for anyone to hold.

  On an event that has a workspace, those writes are shared with that workspace's planners (workspace Manager or Editor). See Role-based access and visibility for internal and external stakeholders. They carry the same confirmed-state constraint 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 stays with the event's finance owner, as it does on any other event.

Adding attendees to a record-only meeting

1. In Onomi 360, open the event and select the Attendees section of the event record. It lists 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 sits with a holder of the finance role whose scope covers the event. That is the same grant that carries the attendance state on this lane, because there is no workspace planner membership for anyone to hold.
3. Set the Registrant type field. With no registration form to carry it, the type is chosen 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).

   The type is set as the attendee is added. The event record's attendee list carries no control for changing it on a row that has been saved. The writes that list carries are Add attendee and the Show and No-show state (see Role-based access and visibility for internal and external stakeholders). So check the type before you select Save, because the row stays inside or outside the disclosable population as entered. That 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.

   Where a type has to be corrected on a row already saved to the event record, please contact your SpotMe Account Manager, 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. The resolution state, and the master identifiers it resolved to, show 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 rather than an audience. A meeting large enough for a list to be loaded rather than typed belongs to a request category that creates a workspace.

The same holds for a record-only meeting whose event record arrived already approved from your CRM rather than from a request. That means one whose request category on the connector's inbound field mapping maps to record-only. The connector's inbound event mapping carries the event's own attributes and no attendee list. So those attendees are added here too, one at a time, with Add attendee (see Integration patterns: connecting Onomi to your enterprise systems). An arriving record whose category maps to a workspace instead is not on this lane, and follows the workspace's own registration paths.

Record-only meetings run without registration, without check-in, and without consent capture on the event, and the boundary is deliberate. A two-person office visit does not need a registration journey to be a compliant record. So no consent wording is presented and no signature is captured at a registration step for these meetings. There is no session-level attendance behind the event-level state. What the record carries 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 reach your CRM on Meeting record sync, outbound. Integration patterns: connecting Onomi to your enterprise systems documents that flow. The record lands as the CRM objects your organization configures, and it carries the attendance state recorded on each attendee. The state carried is the one on the attendee's row, which reads No state recorded where none has been set, so an unrecorded attendance still syncs as a row rather than being withheld.

That flow runs on the Veeva SpotMe Sync App connector, the documented route for the record-only lane. Where your organization's HCP master is Salesforce, the route that carries 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 stays on the event record, and it reaches your transparency systems through the handoff described below.

Attendees of a record-only meeting hold no platform account, so the in-app Privacy & Legal path does not reach 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 the status in the header shows Open.

   

2. Review the cost lines. Each line shows the 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.
3. 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. So a fee line that named its speaker at capture arrives here already attributed, and setting it here shows on the budget line (see How to use the Budget module). Only what the two pickers offer differs.

   Where the recipient is not yet set, select it from the list this field offers. That list holds the attendees recorded as present whose registrant type is 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. That is how a line legitimately comes to name someone who was not recorded present. Step 4 says what the allocation does with it.

   Optionally, change a line's Transfer of value category or Attribution where the inherited default does not fit that specific cost; the change applies to that line only.

   Two grants hold these preparation writes: the planners of the event's workspace (workspace Manager or Editor), and holders of the finance role whose scope covers the event. On a meeting with no workspace, a holder of the finance role holds them alone, 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. Where 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 stays empty and this step is not needed.

4. 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 whose registrant type is ToV-relevant. Amounts use the number of decimal places of the event currency, normally two. Where an equal share does not divide exactly, the last row carries 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.
   • Where no cost line on the event carries an actual amount, the run stops with "There is nothing to allocate. No cost line on this event carries an actual amount."
   • Where 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 stays on the event as the Unattributed remainder. An amount lands there in these cases:

   • An individual line whose recipient 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 whose registrant type 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 whose identity is unresolved.
   • The whole amount of a shared line with no disclosable population, meaning a shared line on an event where no attendee recorded present carries a ToV-relevant registrant type. That is the outcome the warning above describes.

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

   When no recipient is set. An individual line whose Recipient was never set is treated the same way as one naming somebody outside the disclosable population. There is nobody to attribute it to. So its amount sits in the remainder with that reason recorded against it, rather than being distributed or dropped. That is what keeps the totals in step 6 true. 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 rather than 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. That 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. That leaves an already-attributed line pointing at someone the allocation can no longer disclose to.

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

   When a shared line carries a stored attendee. A cost line can carry a stored attendee and an attribution of Shared at the same time. 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 whose Attribution is 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. Where 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 rather than 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.

5. Review the result. The Review tab shows one row per attendee whose registrant type is marked ToV-relevant, whatever their attendance state. Each row carries the attendee's name and their attendance state (Show, No-show, or No state recorded). It carries 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 carry amounts. So a no-show and an attendee with no state recorded read as zero in every category. That is the quickest way to see 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 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.

   The entries are grouped by reason, so the remainder reads without opening each line behind it. Select a row to expand it: each amount lists the cost lines it came from and the share of each line the attendee carries.

   

6. 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. So every allocated cost line is either attributed to a disclosable recipient or accounted for in the remainder, with nothing left over and nothing counted twice. An excluded line stays inside that sum. Its amount sits in the remainder rather than dropping out of the total.
7. Ask the event's finance owner to review and confirm. The finance owner opens the same Review tab and selects Confirm allocation. Anyone else reads 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. So a row already saved is put right on the SpotMe Account Manager route set out in Meetings with no workspace above. The alternative this lane holds in the platform 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, rather than carrying a recipient nobody could resolve.

   The block is raised by lines resting on an unresolved identity, in the sense of a named recipient who cannot be resolved. That means an individual line whose Recipient is a person 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 is held in the unattributed remainder with its own reason. So it is visible on the Review tab before filing, rather than 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 stays 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 confirmer's name 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: the status shows 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. So which version you are reading is visible without opening the audit trail.

Correcting a confirmed allocation

A confirmed allocation is never edited in place, and that reaches the cost lines behind it. While a confirmed allocation stands, three things hold 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, rather than written over the confirmed figure.

So the event's finance owner reopens the allocation first. Where 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 attribution is closed on those same terms. It is what the allocation reads to decide whether an amount reaches 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. So neither entry point re-points a line the allocation has read while it stands. 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 reads one sync status per country, with a compact delivery-status line beside it naming what each destination has taken. The correction rule reads the set rather than any one of them. Reopen is withdrawn as soon as the handoff has been delivered to any connected destination. So the first Delivered status closes in-place correction for the allocation as a whole, and a country still reading Not synced does not reopen it. Once a figure has reached one transparency system, correcting it in place would leave that system holding 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 stay on the trail, and no figure from version 1 is overwritten.

  Where the event's financial record has already been exported, export it again. Each confirmed version stays 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 one whose original delivery never succeeded. 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 carries 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 stays 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).

• Where no destination is configured. An organization that reads the confirmed allocation on the event record, without a transparency destination connected, has no delivery to divide before from after. Reopen stays available to the event's finance owner. What bounds it is the record rather than a delivery event. Each re-confirmation writes a new version of the confirmed allocation, carrying 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. Connecting a destination later does not deliver these allocations, because delivery is triggered by confirmation. 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.