Budget setup happens once in Onomi 360, and this guide covers it: the category hierarchy and its GL codes, the per-currency budget bands, and the reporting currency and reference rates. It also covers the finance codes reinvoicing summaries group by, and the budget policies that watch every event budget. For the roles that hold these settings and what to have 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 rather than code: categories, bands, limits, and recipients are edits your administrators make themselves.
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. The new category appears in the hierarchy as soon as you save.
Where your organization also allocates transfer of value, set the category's transfer-of-value classification in the same change. It is set 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 carrying its parent's entry. So a category whose costs your transparency process classifies otherwise is set before the first cost line is booked to it.
The attribution matters as much as the classification. A cost line whose attribution is Shared is distributed across the disclosable population, whatever attendee is stored on it. So 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. The organization hierarchy holds 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.
Each category carries 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 set on sub categories. A main category that only groups sub categories can leave it empty.
Counts toward the meal cap
Yes or no, and no by default. Set it to yes on the categories whose spend your hospitality policy holds against 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 sits under. So mark the categories the spend is actually recorded in, rather than only the main category above them. Where 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. So a line under an event-level sub category of a category marked yes still counts.
A category left at the default contributes nothing to that figure. So a market can carry a meal cap and see no check run until at least one category is marked. The cap itself is set per market with your venue rules. See Setting venue rules in Onomi 360.
Sourcing award target
None, Venue, or Accommodation, and None by default. It marks the categories a sourcing award writes to, 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 writes to that line and to no other. It creates the line it needs, then updates that same line where the award itself changes. So it never selects among the cost lines a planner has already entered. That matters because a category such as Venue normally holds several.
At most one category per value. An organization Admin sets it here, with the rest of the category hierarchy. At most one category carries Venue, and at most one carries Accommodation. So an award always has one target rather than a choice. That ceiling is enforced rather than advisory. Selecting a value another category already carries is refused, and the message names the category holding it, 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 carries it back to None and saving, then setting it on the category that should hold it.
A request that carries both. A sourcing request that carries both the meeting space and the bedroom need is a venue request. Its whole award commits to the category set to Venue, and it occupies the venue award target. The ceiling of one request per target is unchanged. Room spend belongs in the category set to Accommodation only where 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 writes to, rather than classifying a line already recorded under it. A sourcing award therefore always writes to the organization-level category carrying the value. Event-level sub categories leave the ceiling of one category per value untouched. Set both before your first sourcing request.
Where the target is missing or retired. Two states leave an award with no target: no category carries the value the award needs, and the category that carries it has been retired. In both, the budget write is refused rather than applied, on the same terms as the other states that refuse it. The award records that its budget write was blocked, because no category carries 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 where no owner has been named (see Assigning the finance owner in Reconciliation, invoices, and closing the event).
The award stays on the event record with its amount and its supplier. The awarded amount lands in the Committed column as soon as an active category carries the matching value. See How to source a venue from your event.
Active
On by default. Turn it off to retire a category. It then stops appearing when new cost lines are created. It stays visible on the event budgets that already use it. Retirement reaches the two settings the platform reads on a category for itself, and it reaches them differently.
Where the category carries Sourcing award target. Where the retired category carries Sourcing award target, an award has no line it can create under it. So the automatic write is 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 where no owner has been named (see Recording committed costs in Budget capture at request and working the budget during planning).
The award stays on the event record with its amount and its supplier. The awarded amount lands in the Committed column as soon as an active category carries the matching value. At most one category carries each value. So moving the target means clearing the value on the retired category and setting it on an active one.
Where the category counts toward the meal cap. Where the retired category is marked Counts toward the meal cap, the cost lines already sitting under it keep counting toward the reconciliation check. That setting is read on the category each cost line sits under. A retired category also stays 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. The hierarchy you defined is offered, 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 a band is drawn 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. The threshold itself is set 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 holds up to 50 bands per currency, so plan each currency's set as an additive one. Where your organization has reached that ceiling, contact your SpotMe Account Manager.
Editing a band reaches the events already approved in it. The approved band carried onto an event budget is the band rather than a figure. Every comparison the budget header runs takes one figure from it, the band's To value. So changing From or To restates the approved band 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 rather than as a tidy-up. That organization-level edit is a different act from changing the approved band of one event. That 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 reads 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. The conversion applies to 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 holds up to 100 currencies and retains rate history per effective date. Maintain it by editing rows directly, or by importing a CSV file with those three columns and up to 500 rows. The current table downloads 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 stays 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. A corrected table can then be checked against the file that produced it.
Note: Conversion is a reporting device. Every event budget, policy evaluation, and allocation stays 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 reinvoices 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 rather than a surface 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. That filter is what makes it a reconciled-costs summary. The costs entity itself carries 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 your administrators 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 carries. Choose it before those fields are completed.
- Complete the three shared fields described below, then the fields of the type you selected.
- Select Save. The policy appears on the policy list, and each policy you create is enforced as soon as you save it.
- Repeat for each policy your organization needs, and for each currency it wants a threshold policy in. A policy is edited in place, and it cannot be removed or deactivated once created. The tab holds up to 50 threshold policies per currency and up to 50 blank-cost policies per organization. Each policy holds up to 20 notification recipients. Plan the set before you build it. Where your organization has reached a ceiling, 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 carries 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 it raises notifies its recipients on the terms published below:
- A threshold policy whose scope covers the line fires where the settled Actual value crosses its limit, flagging the line. Where the roll-up it reads crosses the limit, the flag sits on the budget header.
- A blank-cost policy at its reconciliation-stage reading flags the lines in scope still carrying no Actual amount, and holds the Incomplete indicator on the budget header.
- A settled Actual total that passes the approved band raises 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 rather than from a person.
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 reads. Applied to the whole event budget, it reads every cost line and the event total. Applied to one category, it reads that category's lines and the category roll-up, and nothing outside them. So a policy can act on hospitality lines without touching the rest of the budget.
The category the field offers is a main category or a sub category. Which level you pick decides how far the scope reaches:
- A policy applied to a main category reads 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 reads that sub category's cost lines and its roll-up alone.
A main category that groups sub categories and holds no lines of its own therefore still gives a policy the lines under it to read.
What each type then does inside that scope differs. A threshold policy compares its limit against the lines and the roll-up it reads. A whole-budget threshold fires both when a single line crosses the limit and when the budget's own total does. A category threshold fires on that category's lines and its roll-up alone. A blank-cost policy looks for missing amounts among the lines it reads.
Notification recipients
The people notified when the policy raises 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 whose scope covers those events. Every exception the policy raises then reaches someone who can act on it.
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 fires 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. That roll-up is the event total for a whole-budget policy, and the category roll-up for a category policy.
When it fires on a line, the recipients are notified and the line is flagged on the budget. When it fires on a total, the flag sits on the budget header. Either way the exception stays visible on the record until it is resolved.
Blank-cost policy catches the cost lines whose amount has not been recorded, and which column it reads 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 reads the same pair.
Before the boundary, while the event is planned. Before it, while the event is being planned, the policy reads the Budgeted column. It flags a line in scope only where the line carries no amount in any column. A line that already carries a figure is not blank. That 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 hold the budget header at Incomplete. That 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 carrying no figure at all.
From the boundary, at reconciliation. From the boundary, at reconciliation, the policy reads the Actual column. It flags a line in scope carrying 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. A cancelled event therefore reads 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 covers every event budget in your organization.
A record carrying neither date. A record carrying neither date gives that boundary no date to read. The policy then reads 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 where the connector's inbound field mapping carried 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 where 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 reads, the budget header shows an Incomplete indicator. The blank lines are flagged, and the recipients are notified. So a budget cannot read as complete while numbers are missing.
Crossing the boundary. Crossing the boundary re-reads the column rather than triggering 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.
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 notification reaches the recipients 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 fires on the event total with its flag 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. Read that limit from your finance organization rather than 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 rather than the line being 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 stays 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 whose scope 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 where 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 whose scope covers those events, 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. So a test threshold left low keeps firing 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.