Budget setup happens once in Onomi 360, and this guide explains what you set up: the category hierarchy and its GL codes, the per-currency budget bands, and the reporting currency and reference rates.
It also explains the finance codes reinvoicing summaries group by, and the budget policies that watch every event budget.
For the roles that can change these settings and what you need in place first, see How to use the Budget module.
Setting up budgets in Onomi 360
Budget structure and policies are defined once at the organization level, so every event works against the same categories and the same rules.
All of it is settings, not code: categories, bands, limits, and recipients are edits you make yourself.
Categories and GL codes
The Budget module organizes costs into a category hierarchy with two levels: main categories and sub categories.
You can shape both to your procurement requirements. The hierarchy starts empty. Define it before the first event budget is created.
- In Onomi 360, open Budget & finance.
- In the Categories tab, select Add category and complete the fields described below. You see the new category in the hierarchy as soon as you save.
If your organization also allocates transfer of value, set the category's transfer-of-value classification in the same change. You set it in the Category mapping at Onomi 360 > Policies > Transfer of value.
A new organization-level main category is created there classified as hospitality, with Default attribution Shared. An organization-level sub category is created with its parent's entry.
If your transparency process classifies a category's costs otherwise, set the mapping before the first cost line is booked to that category.
The attribution matters as much as the classification. A cost line with attribution Shared is distributed across the disclosable population, whatever attendee is stored on it.
Set a category for speaker fees, honoraria, or consulting to Transfer of value category fees for service, with Default attribution Individual.
Set it in Onomi 360 > Policies > Transfer of value before the first cost line is booked to it.
Otherwise its honoraria are divided across the attendance instead of resting on the person paid. See the Cost category mapping section of Setting up transfer of value and cost category mapping.
- Repeat for each main category and, under each one, for the sub categories your procurement structure requires.
You can have up to 100 main categories, each with up to 100 sub categories. Event-specific sub categories count against the second level on that event only.
Define category fields
Each category has the following fields:
Category name
The label planners see when they add cost lines, for example Venue, Catering, or Audiovisual.
Parent category
Empty for a main category. Select a main category to create a sub category under it. The hierarchy supports these two levels.
GL code
The general ledger code applied by default to every cost line created in this category. Each line books to the right account without the planner looking codes up. Planners can change the code on an individual line. Usually you set it on sub categories. You can leave it empty on a main category that only groups sub categories.
Counts toward the meal cap
Yes or no, and no by default. Set it to yes on the categories your hospitality policy counts toward the per-person meal cap. Those are normally the catering and food and beverage categories your planners book to. An organization Admin sets it here, with the rest of the category hierarchy. One organization-level decision then governs every event.
At reconciliation the check sums the reconciled actuals on the categories marked yes.
It compares the resulting per-person figure against the meal cap of the event's market (see Reconciling the budget in Reconciliation, invoices, and closing the event).
The setting is read on the category each cost line is under. Mark the categories the spend is actually recorded in, not only the main category above them.
If that category is an event-specific sub category a planner added on an event budget, the value read is the one on its parent main category.
A line under an event-level sub category of a category marked yes therefore still counts.
A category left at the default contributes nothing to that figure. A market can therefore have a meal cap and see no check run until at least one category is marked.
You set the cap itself per market, with your venue rules. See Setting venue rules in Onomi 360.
Control sourcing award targets
Sourcing award target
None, Venue, or Accommodation, and None by default. It marks the categories a sourcing award's cost line is created under, so an award books to the same place on every event whatever your categories are called. Awarding a venue bid creates a cost line of its own under the category marked Venue. Awarding a rooms-only room block does the same under the category marked Accommodation. The awarded amount lands in the Committed column attributed to the award (see Recording committed costs in Budget capture at request and working the budget during planning).
The award books to that line and to no other. It creates the line it needs, then updates that same line if the award itself changes.
It never selects among the cost lines a planner has already entered. The distinction matters because a category such as Venue normally has several.
At most one category per value. An organization Admin sets it here, with the rest of the category hierarchy.
At most one category has Venue, and at most one has Accommodation. An award therefore always has one target, not a choice. The limit is enforced, not advisory.
Selecting a value another category already has is refused, and the message names that category, for example "Venue is already the Sourcing award target of the category Venue hire. Clear it there first, or choose another value." Move the value by setting the category that has it back to None and saving, then setting it on the category that should have it.
A request with both needs. A sourcing request with both the meeting space and the accommodation requirements is a venue request.
Its whole award commits to the category set to Venue, and it occupies the venue award target.
The limit of one request per target is unchanged. Room spend belongs in the category set to Accommodation only if the bedrooms are run as a separate rooms-only request.
Read on the organization hierarchy only. The setting is read on the organization-level hierarchy only.
An event-specific sub category a planner adds on an event budget does not take it from its parent main category.
The other settings that parent passes down do reach it. This one is read the other way round.
It finds the category an award books to. It does not classify a line already recorded under it. A sourcing award therefore always books to the organization-level category with the value.
Event-level sub categories leave the limit of one category per value untouched. Set both before your first sourcing request.
A missing or retired target. Two states leave an award with no target: no category has the value the award needs, and the category that has it has been retired.
In both, the budget write is refused, not applied, on the same terms as the other states that refuse it.
The award records that its budget write was blocked, because no category has the Sourcing award target it needs or because its target category is retired. 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 if no owner has been named (see Assigning the finance owner in Reconciliation, invoices, and closing the event).
The award remains on the event record with its amount and its supplier.
The awarded amount lands in the Committed column as soon as an active category has the matching value. See How to source a venue from your event.
Retire a category safely
Active
On by default. You can retire a category by turning it off. It then stops appearing when new cost lines are created. It remains visible on the event budgets that already use it. Retirement affects the two settings the platform checks on a category for itself, and it affects them differently.
A retired category with Sourcing award target. If the retired category has Sourcing award target set, an award has no line it can create under it.
The automatic write is therefore refused, on the same pattern as the other refusals.
The award records that its target category is retired, 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 if no owner has been named (see Recording committed costs in Budget capture at request and working the budget during planning).
The award remains on the event record with its amount and its supplier. The awarded amount lands in the Committed column as soon as an active category has the matching value.
At most one category has each value. Moving the target therefore means clearing the value on the retired category and setting it on an active one.
A retired category that counts toward the meal cap. If the retired category is marked Counts toward the meal cap, the cost lines already under it keep counting toward the reconciliation check.
The setting is read on the category each cost line is under. A retired category also remains visible on the event budgets that already use it.
To verify the setup, open a test event's Budget module in Onomi 360 and add a line. You see the hierarchy you defined, and the line's GL code prefills from its category.
Note: Planners can adapt the hierarchy for an individual event by adding event-specific sub categories on the event budget. An event-level adaptation never changes the organization hierarchy.
Budget bands and currencies
Requesters do not enter line-level figures. They select a budget band on the request form. Bands are defined here and referenced by your approval rules.
- In Budget & finance, open the Bands tab.
- Select Add band and complete the fields below. The band is offered on the request form the next time a requester opens it.
Band label
The text the requester sees, for example "10,000 to 25,000" or "Above 100,000".
From and To
The bounds of the band. Leave To empty for the open-ended top band. How you draw a band also decides whether it can qualify for auto-approval, because auto-approval compares a band with an amount threshold. A band qualifies only when its To value is at or under the threshold. A band that straddles the threshold does not qualify. The open-ended top band, with To left empty, never qualifies. You set the threshold itself in Configuring approval routing, the compliance gate, and auto-approval.
Currency
The currency the band is defined in. Define your band set once per currency your organization requests events in. The requester sees the bands that match the currency they select.
The currency selected on a request becomes the budget currency of the resulting event. Every line, column, and roll-up on that event budget is recorded and displayed in it.
A band is edited in place. No control on the Bands tab removes, retires, or deactivates one.
The tab has room for up to 50 bands per currency, so plan each currency's set as an additive one. If you have reached that limit, contact your SpotMe Account Manager.
Editing a band affects the events already approved in it. What an event budget keeps as its approved band is the band itself, not a figure.
Every comparison the budget header runs takes one figure from it, the band's To value.
If you change From or To, the approved band is restated on every event budget already approved in that band, from the next evaluation onward.
It moves the amount available against the band, the over-band flag, and whether that band qualifies for auto-approval with it.
Change a band's bounds deliberately, not as a tidy-up. The organization-level edit is a different act from changing the approved band of one event.
The per-event change is made on that event's budget header by selecting another band (see Budget capture at request and working the budget during planning).
Note: Approval routing uses the band, not a free figure.
The mapping from budget band to approvers, together with attendee type and request category, is configured in the Approval rules tab of Policies; see Configuring approval routing, the compliance gate, and auto-approval.
Reporting currency and reference rates
Each event budget lives in one currency, the currency selected on its request, and it is never converted. Cross-event views are different.
Cross-event reports and the dashboards in Insights convert into a single reporting currency, so figures can be compared and totaled across markets.
- In Budget & finance, open the Currencies tab.
- Set the Reporting currency and maintain the reference-rate table described below. You see the conversion in cross-event views from the next time they load.
Reporting currency
The currency cross-event roll-ups and reports convert into. One per organization.
Reference-rate table
The exchange rates the conversion uses, one row per currency: the currency, its rate to the reporting currency, and the date the rate takes effect. The table has room for up to 100 currencies and retains rate history per effective date. You can maintain it by editing rows directly, or by importing a CSV file with those three columns and up to 500 rows. You can download the current table as the import template.
An import is all or nothing. A row the file cannot supply is reported with its line number, for example "Row 12: rate must be a number greater than 0. No rows were imported." The table remains as it was until the file is corrected.
An import that succeeds returns a summary of the rows it added and the rows it replaced. You can then check the corrected table against the file that produced it.
Note: Conversion is a reporting device. Every event budget, policy evaluation, and allocation remains in its own currency; only cross-event views and the reporting-currency equivalents on reinvoicing summaries use the reference rates.
Finance codes for reinvoicing
If your organization uses reinvoicing for event costs across countries, cost centres, or legal entities, master the finance codes here so reinvoicing summaries can group by them.
- In Budget & finance, open the Finance codes tab. Both lists start empty.
- In the Cost centres list, select Add cost centre, enter the cost centre, and save.
It is available on every event budget header as soon as you save. Repeat for each cost centre your events charge to.
- In the Intercompany codes list, select Add intercompany code, enter the code, and save. It becomes available on the same header on the same terms. Repeat for each code your legal entities cross-charge with.
- Maintain the two lists here as your finance structure changes. Both are described below.
Cost centres
The cost centres events can charge to. On each event, the planner or finance owner sets the Cost centre field on the budget header.
Intercompany codes
The codes used for cross-charging between your legal entities. Set per event in the Intercompany code field on the budget header.
A reinvoicing summary is a saved custom report on the costs entity of the Onomi 360 report builder, not a screen of its own.
It groups by event country, cost centre, and intercompany code, and reports in the event currency with the reporting-currency equivalent alongside.
The person building it sets a filter that narrows it to the reconciled lines. The filter is what makes it a reconciled-costs summary.
The costs entity itself includes every cost line on the event records in the cut, reconciled or not.
See Building a reinvoicing summary in How to use Onomi 360: the portfolio calendar, engagement view, and reports.
Budget policies
Budget policies are managed in Budget & finance, in its Policies tab. No policy exists by default, so the set is the one you create, one policy at a time.
- In Onomi 360, open Budget & finance.
- In the Policies tab, select Add policy.
- Select the policy type: a threshold policy or a blank-cost policy. The type decides which fields the form asks for below the three every policy has. Choose it before you complete those fields.
- Complete the three shared fields described below, then the fields of the type you selected.
- Select Save. You see the policy on the policy list, and each policy you create is enforced as soon as you save it.
- Repeat for each policy you need, and for each currency your organization wants a threshold policy in. A policy is edited in place, and it cannot be removed or deactivated once created.
The tab has room for up to 50 threshold policies per currency and up to 50 blank-cost policies per organization.
Each policy can name up to 20 notification recipients. Plan the set before you build it. If you have reached a limit, contact your SpotMe Account Manager.
Of the two types, only the threshold policy is defined in a currency, because only it compares an amount. A threshold policy watches the event budgets kept in its own currency.
An organization operating in several currencies defines it once per currency it wants watched.
A blank-cost policy has no amount and no currency, so one policy applies organization-wide, to every event budget whatever currency it is kept in.
Policies are evaluated when a cost line is saved. A cost line is saved whether a person enters the amount or an invoice from your ERP settles the line's Actual amount.
A settlement therefore evaluates that budget's policies exactly as a typed cost-line save does. Each exception notifies its recipients on the terms published below:
- A threshold policy with the line in its scope flags the line if the settled Actual value crosses its limit. If the roll-up in its scope crosses the limit, the flag appears on the budget header.
- A blank-cost policy at its reconciliation-stage reading flags the lines in scope that still have no Actual amount, and keeps the Incomplete indicator on the budget header.
- A settled Actual total that passes the approved band puts the over-band flag on the budget header, and notifies the event's finance owner.
No exception is missed because the amount arrived from your ERP instead of from a person.
Complete the shared policy fields
Both types share three fields:
Policy name
The label shown on the policy list and in its notifications.
Applies to
The whole event budget (the default) or one category. The scope narrows which cost lines and which roll-up a policy checks. Applied to the whole event budget, it checks every cost line and the event total. Applied to one category, it checks that category's lines and the category roll-up, and nothing outside them. You can therefore point a policy at hospitality lines without touching the rest of the budget.
The category the field offers is a main category or a sub category. The level you choose decides how far the scope goes:
- A policy applied to a main category checks the cost lines saved under that main category, the cost lines under its sub categories, and its roll-up.
- A policy applied to a sub category checks that sub category's cost lines and its roll-up alone.
A main category that groups sub categories and has no lines of its own therefore still gives a policy the lines under it to check.
What each type then does inside that scope differs. A threshold policy compares its limit against the lines and the roll-up in its scope.
A whole-budget threshold is triggered both when a single line crosses the limit and when the budget's own total does.
A category threshold is triggered by that category's lines and its roll-up alone. A blank-cost policy looks for missing amounts among the lines in its scope.
Notification recipients
The people notified when the policy finds an exception: the ones responsible for acting on it. Name at least one recipient who works the budgets the policy governs, normally holders of the finance role with those events in their scope. Every exception the policy finds then goes to someone who can act on it.
Configure a threshold policy
Threshold policy watches costs against a limit you set.
-
Limit: an amount and its currency, the one field that gives this type a currency.
A threshold policy evaluates in its own currency: it applies to the event budgets kept in that currency, and an organization operating in several currencies defines the policy once per currency.
The policy is evaluated every time a cost line is saved. It is triggered when any value inside its scope crosses the limit.
Those values are the Budgeted, Committed, or Actual value of a line in scope, plus the roll-up of what the policy applies to.
The roll-up is the event total for a whole-budget policy, and the category roll-up for a category policy.
When it is triggered on a line, the recipients are notified and the line is flagged on the budget.
When it is triggered on a total, the flag appears on the budget header. Either way the exception remains visible on the record until it is resolved.
Configure a blank-cost policy
Blank-cost policy catches the cost lines with an amount that has not been recorded, and which column it checks follows the stage the event is in.
The boundary between the two stages is the End date on the event record. On a cancelled event it is the cancellation. The Reconciliation reminder uses the same pair.
Before the boundary, while the event is planned. Before it, while the event is being planned, the policy checks the Budgeted column.
It flags a line in scope only if the line has no amount in any column.
A line that already has a figure is not blank. The exemption matters because the module records mature costs straight into Committed.
A line created with a Committed amount is not flagged as blank during planning, and does not keep the budget header at Incomplete.
The amount can be a commitment someone typed, a reimbursement claim the meeting team routed, or the amount a sourcing award wrote.
What the Incomplete indicator reports during planning is the lines with no figure at all.
From the boundary, at reconciliation. From the boundary, at reconciliation, the policy checks the Actual column. It flags a line in scope with no Actual amount.
Those lines are the outstanding-actuals signal the finance owner works from at step 3 of Reconciling the budget in Reconciliation, invoices, and closing the event.
What is outstanding at that stage is the final cost, so a Budgeted or Committed figure on the line does not exempt it there.
On a cancelled event the policy therefore checks the Actual column from the cancellation, the moment its reconciliation starts.
No fields of its own. It has no additional fields and no currency, so one policy applies to every event budget in your organization.
A record with neither date. A record with neither date gives that boundary no date to read.
The policy then checks the Budgeted column there until dates are set on the event record. Two things produce that state, and the rule is the same whichever did.
An event approved upstream in your CRM arrives in it if the connector's inbound field mapping supplied no dates.
See the Events approved upstream in your CRM section of From approval to execution and auditing requests.
An event created from an approved request arrives in it if the request category omitted the Proposed dates field, or left it optional and unanswered.
Approval then had no date to take (see step 6 of Configuring the request form and its categories in the same article).
While a line in scope is blank. While any line in scope is blank on the terms its stage checks, the budget header shows an Incomplete indicator.
The blank lines are flagged, and the recipients are notified. A budget therefore cannot show as complete while numbers are missing.
Crossing the boundary. Crossing the boundary changes the column the policy checks. It does not trigger a notification of its own.
The lines newly flagged there show in the Incomplete indicator on the budget header and in the line flags.
The recipients are next notified when the policy is evaluated on one of its own triggers: a cost-line save, or the reconciliation check.
Note: Notification recipients are set per policy, so a threshold on hospitality costs can alert a different person than a blank-cost policy watching the whole budget.
Verify the policies
To verify your policies, create a threshold policy with a deliberately low limit in the currency of a test event.
Save a cost line on that event above the limit. Confirm the recipients are notified and the line shows its flag.
Then verify the total as well. Raise the limit above every single line on the test event but below their sum.
Save a line, and confirm the whole-budget policy flags the event total on the budget header.
Then take the test threshold out of the way as soon as both checks pass. Edit the policy to a limit above anything an event in that currency could have been approved for.
Keep at least one notification recipient on it. Take the limit from your finance organization, not from the band set.
An event budget can pass the To value of the band it was approved in. Cost lines can be entered above the approved band.
The amount available goes negative, and the line is not refused (see Budget capture at request and working the budget during planning).
Do not empty the recipient list. A policy cannot be removed or deactivated once created, so the test policy remains in that currency for good.
At reconciliation, the Meal cap exceeded flag notifies the recipients of every threshold policy kept in the event's budget currency that covers a category that counts toward the meal cap.
A whole-budget policy in that currency is included. The flag falls back to the event's finance owner only if no such policy exists (see Reconciling the budget in Reconciliation, invoices, and closing the event).
A whole-budget policy left standing with an empty recipient list therefore silences that flag on every event budgeted in that currency.
Name the holders of the finance role with those events in their scope, or the compliance reviewers this article recommends naming on a policy of this kind.
The policy then keeps an audience for as long as it exists.
A policy applies to every event budget kept in its currency for as long as it exists. A test threshold left low therefore keeps notifying across your organization.
For what this module does and where its boundaries are, see How to use the Budget module.
* Onomi 360 MeetingsEQ exclusive capabilities.
Comments
0 comments
Please sign in to leave a comment.