Budget capture at request and working the budget during planning

This guide follows the budget from the meeting request into planning. It covers 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 fires. 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 carries 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 carry over to the event as the approved band on the budget header. What carries over is the band, not a figure. The event budget opens with no cost lines. The lines the planner adds 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 rather than 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. That 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 reads those same two values. Threshold policies watch the event budgets kept in their own currency. The over-band flag reads 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. So where 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 rather than a refinement.

Where the mapping carries 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 read 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 writes one amount to a budget on its own: a sourcing award landing its awarded amount in the Committed column. On such an event that write is refused rather than applied. The award records that the budget write was blocked because the event's budget carries 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. The notification is held where no owner has been named. The awarded amount lands once a band in the award's currency is set on the header.

Where such a record has already arrived, the band is set on that record, on its budget header. The rule that covers any budget header carrying 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. So the band is set on the record itself.

The mapping itself is documented in Integration patterns: connecting Onomi to your enterprise systems. What else an arriving record carries, with the controls that do and do not act on it, sits in the Events approved upstream in your CRM section. That section is in From approval to execution and auditing requests.

Working the budget during planning

Once the request is approved, the working budget is managed in Onomi 360. Open the event and select the Budget module. Name the event's finance owner on the budget header at this point, rather than 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 carried over from the approved request. Beside them it shows the budget's own totals and the amount still available against the band. So the planner can see the detailed budget against the band it was approved within.

What the header carries is a band rather than a figure. So every comparison it runs 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 reads its headroom against both, rather than switching from one figure to the other at a boundary nothing defines.

The over-band flag watches both totals at all times. An event whose Budgeted total or whose Actual total passes the band's To value carries the flag on the budget header, whatever stage the event is at.

An event approved in the open-ended top band, whose To value is 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. That 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 holds against the limit of 1,000. The room left for a long entry session is visible before the line that would be refused.

Note: The approved band does not block planning. Cost lines can be entered above it, and the amount available goes negative rather than the line being refused. The module makes the condition visible and gives it an owner instead.

An event whose Budgeted or Actual total passes the approved band carries 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, carries the flag on those same terms. It stands from the moment that total passes the band's To value, and stays 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 carried from the approved request is changed on the budget header, by selecting another band of the same currency. That change sits with the same two groups that edit the budget, holders of the finance role whose scope covers the event and the planners of the event's workspace. The change is recorded with who made it and when. Until that change is made, the over-band flag is what carries 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 carry 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 where the connector's inbound field mapping carried neither value (see Events approved upstream in your CRM above). An event created from an approved request arrives in it where the request category omitted the Budget band field, or left it optional and unanswered. Nothing carried over (see How to set up and use meeting requests and approvals).

Either way the band is set on that record, on its budget header, by 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 held in the budget currency. A header carrying none gives a budgeted, committed, or actual amount no currency to be recorded in. So the budget header carries a band before the first line is added. What a planner meets is the control rather than 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. Selecting the first band 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. Every band your organization has defined, in every currency, is offered.

Where a sourcing award is already recorded. Where a sourcing award is already recorded on the event, that first selection decides the budget currency the award has to match. Selecting a band in another currency refuses the award's write on the currency cause instead. The commitment then reaches 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 a run of lines under one category takes fewer selections. Change the selection where this cost belongs elsewhere.
2. Complete the fields below and select Save. The line appears under the category you selected. Each amount is recorded in the column its field writes to. The category roll-up and event total update.

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

Vendor
The supplier the cost sits with.

GL code
Prefilled from the line's category, and from the parent main category where the line sits under an event-specific sub category, which carries no code of its own. Change it when this line books to a different account.

Budgeted amount
The planned cost, entered in the budget currency. It lands in the Budgeted column. Leave it empty when the cost is already agreed or claimed at the moment you record it. The budget currency is what holds the amount. A budget header carrying no band and no budget currency has none to enter it in. Add cost line is unavailable on such a budget rather than refusing the line 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
Used when a cost is already agreed, contracted, or claimed when the line is created. 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 held in the budget currency. So on a budget header carrying no band and no budget currency, Add cost line is unavailable rather than refusing the line 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 reads. Leave it empty when the line is created. On most lines the actual settles by itself. An invoice arrives from your ERP carrying the reference of the cost line it settles. That invoice writes the amount into this field. 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).

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 carries 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 no planner enters it. The commitment your own process raises carries that reference out to the system that raises the invoice. The invoice comes back quoting it, so the match runs on a value both systems already hold.

Where the form of the reference is settled. The exact form of the reference, and how it reaches your ERP, are settled with your SpotMe implementation team when the connection is scoped. The connection itself is documented in the ERP cost and invoice sub-pattern of Integration patterns: connecting Onomi to your enterprise systems.

A final cost with no ERP document. Where a final cost has no ERP document behind it, the event's finance owner enters the amount in this field on the line directly. The same field is where an actual that landed wrong is corrected.

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 rather than at a policy. The event's finance owner reopens the allocation first. Where 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 stays in step with the budget it was computed from.

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 whose registrant type is marked transfer of value relevant. Attendee offers the whole attendee list. That is what makes it possible to book a cancellation fee against someone who then did not attend.

What the allocation reads. The allocation reads the stored value, whichever field set it. Where the value names someone outside the disclosable population, the amount is not attributed to that person. It stays 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 rather than a condition, because the attribution is what the allocation reads. A line whose Attribution is 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 reads the stored attribution to decide whether an amount reaches 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 rather than at a policy. 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 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.

Documents
The supporting evidence attached to the line: the receipt, the invoice, or the claim document. Attached documents stay 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 carries 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.

Optionally, 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 carries 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 holds 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 already sits under. So a line under an event-specific sub category 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 carrying its parent's Default attribution. That setting decides whether the amount is attributed to one named healthcare professional, or divided across the attendees recorded present whose registrant type is marked transfer of value relevant.

Sourcing award target, the fourth per-category setting, is the one it does not take. That setting is read the other way round, to find the category an award writes to. It is read on the organization-level hierarchy only. So a sourcing award always writes to the organization-level category carrying the value. Adding event-specific sub categories never changes the ceiling of one category per value.

Lines can be edited at any time, and roll-ups recalculate as you save. One constraint holds 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.

Optionally, 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 sits with the two groups that edit the budget: holders of the finance role whose scope covers the event, and the planners of the event's workspace. On an event with no workspace, the finance role holds it alone (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 still 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. Where 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).

That second bound reaches 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 rather than 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 the budget reads 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. That is the category 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.

That line is the award's own, and the award updates it where the award itself changes. So no cost line a planner entered is written to, and no rule is needed to choose between the lines a category already holds. 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 rather than 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 writes 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. So the award reaches the Committed column only where two things are true. Its currency matches the event's budget currency, and an active category carries the Sourcing award target it needs.

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

Where the award records a blocked write, the event's finance owner is notified. Where no owner has been named, the refusal is written to the budget header behind the Finance owner not set indicator, and the notification is held.

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 carrying 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 carries 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 carrying no amount on the terms its stage reads. 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 that fires on a roll-up rather than on a line puts its flag on the budget header instead. Either flag stays visible on the record until the figure behind it is resolved.
2. A platform write the budget refuses notifies on its own terms. Where 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. The notification is held where no owner has been named (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 carries the exception until the change is made.

* Onomi 360 MeetingsEQ exclusive capabilities.