Budget capture at request and working the budget during planning

This guide follows the budget from the meeting request into planning. It explains the budget band captured at request, events approved upstream in your CRM, and the working budget in Onomi 360.

The working budget runs from adding cost lines and recording committed costs to what happens when a policy applies. It assumes the organization-level setup in Setting up budgets: categories, bands, and policies.

Budget capture at request

The budget enters the picture with the meeting request, before the first cost is committed:

1. In the meeting request portal, the requester completes the Budget band field on the request form. They choose the band for the meeting and the currency it is requested in.

   No line-level detail is asked for at this stage. The selected band appears on the request record next to its status.

2. The requester selects Submit. The band works as a routing input. Together with the attendee type and the request category, it determines who approves the request.

   An escalation ladder takes high-value requests to senior approvers. The request status moves to Submitted, then In review.

3. The approver sees the requested budget inside the approval itself, with the visible trace of why the request routed to them.
4. On approval, the request status moves to Approved. The approved band and its currency go over to the event as the approved band on the budget header.

   What goes over is the band, not a figure. The event budget opens with no cost lines. The lines you add during planning are its first Budgeted amounts.

To verify, open the request in the portal. The requester sees the requested band next to the request status, and the approver sees the same band inside the approval.

Events approved upstream in your CRM

Your organization may approve events upstream in Veeva CRM Events Management or Veeva CRM Medical Events. Those event records arrive in Onomi 360 already Approved, with no request behind them.

Their budget currency and their approved band come from the connector's inbound field mapping, not from a request form.

The mapped budget band and its currency do the work the request's band and its currency do on the portal lane. The mapped band is the approved band on the budget header.

Every comparison against it uses one figure, the band's To value. The budget is kept in the band's currency and is never converted, exactly as a budget requested in the portal is.

Everything described above then behaves the same way on these events, because it uses those same two values. Threshold policies watch the event budgets kept in their own currency.

The over-band flag checks the band's To value against the Budgeted total and the Actual total alike, at every stage of the event.

The reconciliation meal-cap check runs on the same terms as well. The comparison is made in the currency of the event's market, and nothing is converted.

If that currency differs from the budget currency, the amounts are not compared. The check records that the cap did not apply (see Reconciling the budget in Reconciliation, invoices, and closing the event).

Map the budget band and its currency on the connector before the first upstream event arrives, because both are a prerequisite, not a refinement.

If the mapping supplies neither, the arriving event has no approved band. The budget header shows no band and no amount available. The over-band flag has nothing to check and does not fire.

Two checks need a currency: a threshold policy watching the budgets kept in its own currency, and the reconciliation meal-cap comparison. Both record that they did not apply.

The platform makes one budget write of its own: a sourcing award landing its awarded amount in the Committed column. On such an event that write is refused, not applied.

The award records that the budget write was blocked because the event's budget has no currency, and the event's finance owner is notified.

The refusal is written to the budget header behind the Finance owner not set indicator. If no owner has been named, the notification waits until one is.

The awarded amount lands once a band in the award's currency is set on the header.

If such a record has already arrived, you set the band on that record, on its budget header. The rule for any budget header with no band and no budget currency applies.

See Where a budget header carries no band and no budget currency below.

Correcting the connector mapping fixes the events that arrive after the correction, not the record already created. The band is therefore set on the record itself.

The mapping itself is documented in Connecting CRM, HCP identity, and consent.

What else an arriving record brings, with the controls that do and do not act on it, is in the Events approved upstream in your CRM section of From approval to execution and auditing requests.

Working the budget during planning

Once the request is approved, you work the budget in Onomi 360. Open the event and select the Budget module.

Name the event's finance owner on the budget header at this point, not at reconciliation.

Several of the behaviors below notify that person while planning is still running. See Assigning the finance owner in Reconciliation, invoices, and closing the event.

The budget opens on the category hierarchy, with the three cost lifecycle columns (Budgeted, Committed, Actual) per line and rolled up by category.

The header shows the budget currency and the approved band, the band that came over from the approved request.

Beside them you see the budget's own totals and the amount still available against the band. You can therefore see the detailed budget against the band it was approved within.

What the header keeps is a band, not a figure. Every comparison it runs therefore takes one figure from that band: the To value, the top of the band the request was approved in.

The header shows the amount available against both totals at all times.

Those are that To value less the Budgeted total, and that same value less the Actual total.

An event with three of its 40 cost lines settled therefore shows its headroom against both. Nothing switches the comparison from one figure to the other.

The over-band flag watches both totals at all times.

An event with a Budgeted or an Actual total that passes the band's To value shows the flag on the budget header, whatever stage the event is at.

An event approved in the open-ended top band, with its To value left empty, has no figure to compare against at all.

The header shows the band label, no available amount, and no over-band flag can fire on it.

Watch those events with a threshold policy applied to the whole event budget instead.

The policy compares the event total against a limit you set (see Budget policies in Setting up budgets: categories, bands, and policies).

The header also shows how many cost lines the event has against the limit of 1,000. You can see the room left for a long entry session before the line that would be refused.

Note: The approved band does not block planning. You can enter cost lines above it, and the amount available goes negative; the line is not refused.

The module makes the condition visible and gives it an owner instead.

An event with a Budgeted or Actual total past the approved band shows an over-band flag on the budget header, and notifies the event's finance owner.

An event over its band on the Budgeted total alone, before any actual has landed, shows the flag on those same terms.

The flag stands from the moment that total passes the band's To value, and remains on the header until the band is changed or the totals fall back inside it.

Raising or re-basing the band itself is a separate act. The band that came from the approved request is changed on the budget header, by selecting another band of the same currency.

The change belongs to the same two groups that edit the budget, holders of the finance role with the event in their scope and the planners of the event's workspace.

It is recorded with who made it and when. Until that change is made, the over-band flag is what records the exception, and it is the whole of the control on the approved band.

Where a budget header carries no band and no budget currency

A budget header can have no band and no budget currency at all, and the first band selection on such a header follows a rule of its own.

Two origins. Two things produce that state, and the rule is the same whichever did.

An event approved upstream in your CRM arrives in that state if the connector's inbound field mapping supplied neither value (see Events approved upstream in your CRM above).

An event created from an approved request arrives in it if the request category omitted the Budget band field, or left it optional and unanswered.

Nothing came over (see How to set up and use meeting requests and approvals).

Either way you set the band on that record, on its budget header.

Setting it belongs to the same two groups that change the approved band on any other event. On an event with no workspace, the finance role sets it alone.

No cost line without a currency. No cost line can be created on an event with no budget currency. Every amount on a cost line is kept in the budget currency.

A header with none gives a budgeted, committed, or actual amount no currency to be recorded in. The budget header therefore needs a band before the first line is added.

What you meet is the control, not a rejected save.

Add cost line is unavailable on such a budget, disabled with "This event's budget has no currency yet. Select a budget band on the budget header, then add cost lines." The message names the recovery, the first band selection described below.

The first band selection. The first band you select on such a header is the one band selection that is not constrained to an existing currency, because the record has none yet.

It sets the approved band and the budget currency together. You can choose any band your organization has defined, in any currency.

A sourcing award already recorded. If a sourcing award is already recorded on the event, that first selection decides the budget currency the award has to match.

If you select a band in another currency, the award's write is refused on the currency cause instead.

The commitment then enters the budget as a Committed amount typed on a cost line in the event's budget currency, as that cause documents (see Recording committed costs below).

After the first selection. The selection is recorded on the event record with who made it and when, as a change to the approved band on any other event is.

From then on the record behaves like any other. The same-currency rule above applies to every later change: a further change selects another band of the same currency.

Adding cost lines

1. Select the category or sub category the cost belongs to, and select Add cost line.

   The dialog opens on the category and sub category used on the previous line for this event, so you need fewer selections for a run of lines under one category.

   Change the selection if this cost belongs elsewhere.

2. Complete the fields below and select Save. You see the line under the category you selected. Each amount is recorded in the column that matches its field. The category roll-up and event total update.

Complete the cost line fields

Description
What the cost is, as your finance organization should read it on the closure record.

Vendor
The supplier for this cost.

GL code
Prefilled from the line's category, and from the parent main category if the line is under an event-specific sub category, which has no code of its own. You can change it when this line books to a different account.

Budgeted amount
The planned cost. You enter it in the budget currency, and it lands in the Budgeted column. Leave it empty when the cost is already agreed or claimed at the moment you add the line. The budget currency is what the amount is kept in. A budget header with no band and no budget currency has none to enter it in. Add cost line is unavailable on such a budget instead of the line being refused at save, disabled with "This event's budget has no currency yet. Select a budget band on the budget header, then add cost lines." (see Where a budget header carries no band and no budget currency above).

Committed amount
Use it when a cost is already agreed, contracted, or claimed at the moment you add the line. Examples: a signed speaker fee, a supplier contract, an expense claim handed to the meeting team. The amount lands directly in the Committed column on save, without passing through Budgeted. Leave it empty for a planned estimate, and record the commitment later by opening the line when the cost is agreed (see Recording committed costs).

Like every amount on a cost line it is kept in the budget currency.

On a budget header with no band and no budget currency, Add cost line is therefore unavailable instead of the line being refused at save.

It is disabled with "This event's budget has no currency yet. Select a budget band on the budget header, then add cost lines." (see Where a budget header carries no band and no budget currency above).

Actual amount
The final cost of the line, entered in the budget currency. It lands in the Actual column, which is what the reconciliation pass confirms and what the transfer of value allocation uses. Leave it empty when you add the line. On most lines the actual settles by itself. An invoice arrives from your ERP with the reference of the cost line it settles. The invoice fills this field with the amount. It stamps the line's Invoice reference with the reference the invoice came in under (see Reconciling the budget in Reconciliation, invoices, and closing the event).

Understand references and invoice settlement

The cost line's own reference. The reference the invoice quotes to reach the line is the line's own.

It is not the same value as the Invoice reference the settlement stamps. Every cost line has a reference of its own, and that is what the ERP connection matches on.

It is not one of the fields on the Add cost line dialog above, and not a value you enter.

The commitment your own process raises takes that reference out to the system that issues the invoice. The invoice comes back quoting it, so the match runs on a value both systems already have.

How the form of the reference is settled. The exact form of the reference, and how it gets to your ERP, are settled with your SpotMe implementation team when the connection is scoped.

The connection itself is documented in Connecting finance, procurement, travel, and transparency systems.

A final cost with no ERP document. If a final cost has no ERP document behind it, the event's finance owner enters the amount in this field on the line directly.

An actual that landed wrong is also corrected here.

While a confirmed allocation stands. A confirmed allocation closes this field on its own terms.

While one stands, the Actual amount on a cost line that allocation has read is closed to hand edits, on the same terms as removing the line.

The message points at the allocation, not at a policy. The event's finance owner reopens the allocation first.

If the handoff has already been delivered, the correction follows the versioned Correct allocation path instead (see How to manage transfer of value on your events).

An invoice against such a line. An invoice arriving from your ERP against such a line does not overwrite the confirmed figure either.

It is recorded against the event in the Unmatched invoices view, with the allocation named.

How it settles depends on whether the allocation's handoff has been delivered, on the same two branches as the hand edit.

How that invoice settles. While nothing has been delivered, the event's finance owner reopens the allocation and the invoice is resent.

Once the handoff has been delivered to any connected destination, Reopen is no longer offered.

The correction runs through the versioned Correct allocation path instead. After that the invoice is resent, or the row is dismissed with a reason.

Either way a per-attendee figure your organization has already disclosed remains in step with the budget it was computed from.

Set attendee attribution

Attendee
The participant an individual cost belongs to: the speaker on a fee line, the traveler on an individual flight, the claimant on an expense. The picker lists the event's attendees, whatever their registrant type and whether or not an attendance state has been recorded for them. A cost is often committed before the event happens.

One attribution, two entry points. This is the same stored value as the Recipient field in the event's Transfer of value module.

A value set here shows there, and the other way round. Only the pickers differ.

Recipient offers the narrower population the allocation can disclose to, the attendees recorded present with a registrant type marked transfer of value relevant.

Attendee offers the whole attendee list, so you can book a cancellation fee against someone who then did not attend.

What the allocation uses. The allocation uses the stored value, whichever field set it. If the value names someone outside the disclosable population, the amount is not attributed to that person.

It remains on the event in the unattributed remainder, with the reason shown against it (see How to manage transfer of value on your events).

A shared cost. Leave the field empty for a shared cost (a venue invoice, a group transfer).

Shared lines are distributed at allocation across the attendees recorded as present and marked transfer of value relevant.

Leaving it empty is a convention, not a condition, because the attribution is what the allocation uses.

A line with Attribution Shared distributes across that same 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.

While a confirmed allocation stands. A confirmed allocation closes this field on the same terms as the line's Actual amount, and for the same reason.

The allocation uses the stored attribution to decide whether an amount goes to a named healthcare professional or falls to the unattributed remainder.

Re-pointing a line it has already read would put a per-attendee figure your organization may already have disclosed out of step with the budget it was computed from.

Editing the value. While a confirmed allocation stands, the Attendee value on a line that allocation has read is closed to hand edits.

It closes on the same terms as the Actual amount and as removing the line. The message points at the allocation, not at a policy.

The event's finance owner 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 manage transfer of value on your events).

The other entry point. The Recipient field in the Transfer of value module is the other entry point to the same stored attribution.

It is closed on the same terms. Neither entry point re-points the line while the allocation stands.

Attach evidence and mark claims

Documents
The supporting evidence attached to the line: the receipt, the invoice, or the claim document. Attached documents remain on the record for audit. They travel with an expense claim when it is routed for reimbursement (see How to manage payments, honoraria, and reimbursement on your events).

Reimbursement claim
Off by default. Turn it on when the line records an expense someone is to be reimbursed for. The marker is what makes the line a claim. It gives the line a claim status of its own, separate from the three cost columns. It also puts the Route for reimbursement control on the line. Leave it off for every other cost. An agreed speaker fee or an invoiced individual flight has a Committed amount and an Attendee in exactly the same way, and is not a claim. Without the marker the line has no claim status and no routing control. Claim handling is documented in How to manage payments, honoraria, and reimbursement on your events.

Add event-specific subcategories

You can adapt the hierarchy for this event: select Add sub category inside a main category to create an event-specific sub category.

It exists on this event only, and it has no settings of its own. It takes its parent main category's GL code, its Counts toward the meal cap value, and its transfer-of-value mapping.

The mapping is both settings the Category mapping keeps on that parent.

Those are the Transfer of value category it classifies costs into, and its Default attribution, Individual or Shared (see How to manage transfer of value on your events).

Those three are read on the category a cost line is already under.

A line under an event-specific sub category therefore behaves for each of those checks exactly as a line under its parent main category does.

In the Transfer of value module the line arrives classified as its parent is, and with its parent's Default attribution.

The attribution setting decides whether the amount is attributed to one named healthcare professional, or divided across the attendees recorded present with a registrant type marked transfer of value relevant.

Sourcing award target, the fourth per-category setting, is the one it does not take. The setting is read the other way round, to find the category an award books to.

It is read on the organization-level hierarchy only. A sourcing award always books to the organization-level category with the value. Adding event-specific sub categories never changes the limit of one category per value.

Edit or remove a cost line

You can edit lines at any time, and roll-ups recalculate as you save. One constraint stops an edit.

A confirmed allocation closes the Actual amount and the stored Attendee on a line it has already read, on the terms both field descriptions above set out.

You can remove a line entered in error. Select the line, then select Remove cost line, and confirm.

The line leaves the budget, and the category roll-up and the event total recalculate as soon as it does.

Removal belongs to the two groups that edit the budget: holders of the finance role with the event in their scope, and the planners of the event's workspace.

On an event with no workspace, only the finance role can remove a line (see Role-based access and visibility for internal and external stakeholders).

Two things bound it. Documents attached to the line are removed with it, so keep a copy of anything you need before you confirm.

A line that a confirmed allocation has already read cannot be removed while that allocation stands.

The event's finance owner reopens the allocation first. If the handoff has already been delivered, the correction follows the versioned Correct allocation path instead (see How to manage transfer of value on your events).

The second bound applies to the line's Actual amount on the same terms. While the allocation stands the amount is closed to hand edits, and is reopened the same way.

An invoice arriving from your ERP against the line is recorded in the Unmatched invoices view, not written over the confirmed figure (see the Actual amount field above).

Recording committed costs

A value moves between the columns as the cost matures. When a planned cost is contracted, open the line and enter the contracted amount in the Committed amount field, then select Save.

The Committed column and its roll-ups update, so you see what is contracted next to what was planned.

A cost that is already agreed or claimed the first time it is recorded takes the same Committed amount field on Add cost line instead. It lands in the Committed column in one step.

Awarding a sourcing bid needs no entry at all. The award creates a cost line of its own automatically, attributed to the award.

It lands the awarded amount in the Committed column under the venue or accommodation category.

The category is the one your organization has marked Sourcing award target Venue for a venue award and Accommodation for a rooms-only room-block award.

See Categories and GL codes in Setting up budgets: categories, bands, and policies.

The line is the award's own, and the award updates it when the award itself changes.

No cost line a planner entered is written to, and no rule is needed to choose between the lines already under a category.

The final invoice settles the line's Actual amount through reconciliation, so nothing is re-keyed between sourcing and the budget.

Agreed fees and expense claims captured through Payments and reimbursement land in Committed by the column rule, not by that automatic path.

Each is recorded on a cost line, with the agreed or claimed amount entered in the Committed amount field. See How to manage payments, honoraria, and reimbursement on your events.

Two conditions govern that automatic write: the currency the award comes back in, and the category it books to.

A bid is returned in the currency the supplier quotes it in, and the award made from that bid is expressed in the same currency.

An event budget is kept in one currency, and nothing is converted.

The award therefore goes to the Committed column only if two things are true. Its currency matches the event's budget currency, and an active category has the Sourcing award target it needs.

Four states refuse the write. In all four the award remains on the event record with its amount and its supplier, so nothing is lost.

If the award records a blocked write, the event's finance owner is notified.

If no owner has been named, the refusal is written to the budget header behind the Finance owner not set indicator, and the notification waits.

A retired category stops appearing when new cost lines are created, which is what leaves the award with no target to write to.

Three of the four states recover on their own: the platform applies the refused write once the blocking condition is removed. Only the currency mismatch is recovered by hand.

A header with no band joins it there when the band set on it is in a currency other than the award's.

Note: The purchase requisition behind a commitment is created and processed in your procurement platform, not in the Budget module. The event record keeps the resulting commitment.

The Actual column fills at reconciliation, when final costs and invoices land against the event record from the ERP; see Reconciliation, invoices, and closing the event.

When a policy fires

1. A line crosses a threshold, or a blank-cost policy finds a line in scope with no amount in the column its stage checks.

   The policy notifies its recipients and the flag appears on the budget, so the exception has an owner from the moment it exists.

   A threshold crossed on a roll-up, not on a line, puts its flag on the budget header instead. Either flag remains visible on the record until the figure behind it is resolved.

2. A platform write the budget refuses notifies on its own terms. If a sourcing award's budget write is refused, the event's finance owner is notified on the terms every budget-policy notification follows.

   The refusal is written to the budget header behind the Finance owner not set indicator. If no owner has been named, the notification waits (see Recording committed costs above).

Important: A change to the approved band on an event is never silent.

The band selected, the person who selected it, and the moment they did are recorded on the event record. The over-band flag records the exception until the change is made.

* Onomi 360 MeetingsEQ exclusive capabilities.