This guide closes the financial lifecycle: assigning the finance owner, and reconciling the budget from the invoices and final costs your ERP delivers.
It then explains the meal-cap and unmatched-invoice work you need to clear, closing the event, and exporting its financial record.
It assumes the working budget in Budget capture at request and working the budget during planning.
Reconciliation and closure
Reconciliation is a stage of the event with an assigned finance owner. The person responsible for closing the numbers is named on the event record.
You are reminded from the end of the event until the closure is recorded (see Assigning the finance owner below).
This path is the same whether or not the event has a workspace. Some events have no workspace: record-only meetings, from a request category your organization mapped to record-only.
Such an event reconciles and closes on its event record in Onomi 360, and you use the same Mark reconciled and Close event steps below.
See From approval to execution and auditing requests for how a category is mapped.
A speaker program is a request category, not a record of its own.
Its budget reconciles and closes on its event record with Close event, on the same terms as any other event (see How to run a speaker program).
Assigning the finance owner
Set the finance owner at approval, as soon as the approved request creates the event record, not at reconciliation.
You can set the Finance owner field on the budget header from that moment, and three behaviors address the finance owner before the event closes.
The over-band flag and a refused sourcing-award write both fire while planning is still running.
At reconciliation, the Meal cap exceeded flag notifies the finance owner if no threshold policy kept in the event's budget currency has a meal-cap category in its scope.
The refused sourcing-award write is a set of states, not a single one. Four states refuse the automatic write:
- An award currency differing from the event's budget currency.
- A budget header with no band and no budget currency.
- No category with Sourcing award target.
- A retired target category.
Each of them notifies the event's finance owner (see Recording committed costs in Budget capture at request and working the budget during planning).
- In the Budget module, select the Finance owner field in the header and choose the person responsible for reconciling this event.
The field lists holders of the finance role with this event in their scope and nobody else, so the role assignment comes first.
Assign the role in Onomi 360 > Users and roles with the event in its scope, then name the person here.
You can set the field if you hold the finance role with the event in your scope, or if you are a planner of the event's workspace.
Those are the same two groups that edit the rest of the budget. The name appears on the event record.
- Reconciliation reminders then follow the named owner.
The Reconciliation reminder template goes to the event's finance owner, and it has one trigger.
It starts from the passing of the End date on the event record, and on a cancelled event from the cancellation.
It runs until the closure is recorded, whether or not the budget has unreconciled cost lines.
It repeats at the Reminder frequency until the closure is recorded. What ends it is the closure, not the state of the lines.
A meeting that spent nothing and a budget with every line reconciled are therefore both reminded until someone selects Close event on them.
Start date and End date are fields on the event record itself, documented in From approval to execution and auditing requests. The reminder uses the End date there, not anything kept in a workspace.
An event with no workspace, a record-only meeting from a category mapped to record-only, therefore has the field like any other event record and is reminded on the same terms.
The reminder is the only thing driving that lane to closure.
It is one of the four templates on the Notifications tab that are not triggered by a status change.
No status marks the end of the event. The request status stays In execution, or Approved on a record-only event, until the closure is recorded.
Its cadence is the Reminder frequency your organization sets on the Notifications tab of Policies.
The approval reminders follow that same setting, so a change there moves both. Send reminders, the other setting in that block, governs the approval reminder cycle only.
Turning it off stops the reminders chasing approvers and leaves the Reconciliation reminder running. An administrator cutting approval-email noise therefore does not silence the closure driver on the highest-volume lane.
The event's finance owner is its default recipient, and further recipients are added on the template itself as on any other. Like every notification template it is maintained per language.
Which language it sends in, and which recipients each language goes to, are documented in Languages on the meeting request portal and notifications in Running multilingual events across global markets.
See Configuring notifications for requests and approvals for the Notifications tab.
Note: The field has no default, so nobody is the finance owner of an event until someone is named.
While it is empty, every flag that would notify the owner is still written to the budget header, so no exception is lost. The notification waits; it is not sent to anyone else.
The budget header shows a Finance owner not set indicator, and the waiting notifications go out as soon as an owner is named. The Reconciliation reminder behaves the same way.
The event's finance owner is its only default recipient, so while the field is empty the reminder waits and is not sent to anyone else.
It goes out as soon as an owner is named.
That reminder is the only thing driving a record-only meeting to closure. An organization running record-only categories at volume therefore names the owner as each record is created.
No meeting on that lane is then left with the field empty and its reminder held back. This is why the field belongs at approval, not at closure.
Note: As the named owner you get the controls that come with the assignment: Mark reconciled and Close event here, and Confirm allocation, Reopen, and Route for reimbursement in the modules that use them.
If the finance role is later removed from that person, or its scope is narrowed so it no longer includes the event, the change takes effect immediately.
Those controls stop resolving for them, while everything they already did remains recorded with their name.
The field keeps the name until someone sets it to another holder of the finance role, and the reconciliation reminders follow the new owner.
Removing or changing a scoped role is documented in Assigning roles, enterprise sign-in, and provisioning.
Reconciling the budget
Invoice and final cost transfer opens the pass. The reconciliation below starts from the final costs and invoices your ERP delivers against the event record, and it ends when you have confirmed every line.
1. Match invoices and final costs
Final costs and invoices land against the event record from the ERP, settling the cost lines they belong to. An invoice arrives that way and no other.
Your ERP sends it, and it is matched on the cost line's own reference. The commitment sends that reference out to the ERP, and the invoice quotes it back.
The module has no upload control, and nobody keys an invoice in by hand.
If a final cost has no ERP document at all, you enter the actual on the line directly instead. It is the manual path and the only one.
How the match runs. The invoice includes the event's reference and the reference of the cost line it settles, and the match runs on them in that order.
An invoice can resolve to an event and still match no cost line on it.
The invoice is recorded against the event as unmatched and read in the event's Unmatched invoices view. It does not settle the wrong line, and it does not create one.
An invoice in another currency. An event budget is kept in one currency, and nothing is converted.
An invoice in a currency other than the event's budget currency is therefore not applied to the cost line.
It is recorded against the event alongside the unmatched invoices, and listed for the event's finance owner. The integration posts in the event's budget currency, which is the value the connection expects.
Two further causes. Two further causes put an invoice in the same place.
An invoice with a GL code that matches no category in your organization's hierarchy has no category to book to, so it is not applied to a line either.
It is recorded against the event in the Unmatched invoices view, with the GL code named as the value that failed to match, for example "GL code 6430: no matching category".
It does not notify anyone. It settles in one of three ways:
- The invoice is resent with a code from your hierarchy, together with the reference of the line it settles.
- You match the row to the line with Match to cost line.
- You enter the actual on that line and dismiss the row with a reason.
See Categories and GL codes in Setting up budgets: categories, bands, and policies.
An invoice against a confirmed allocation. An invoice against a line a confirmed allocation has already used is not applied over the confirmed figure either.
It is recorded against the event in the Unmatched invoices view, with the allocation named, and it does not notify anyone. How it settles depends on whether the allocation's handoff has been delivered.
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 (see Running and correcting an allocation).
The Unmatched invoices view. You see every invoice the match refuses in the Unmatched invoices view on the event's Budget module.
Each row shows the invoice reference, the settled amount and its currency, the invoice date, and the value that failed to match. A row leaves the view in one of two ways:
- The invoice is matched to the cost line it belongs to. The match settles the line and takes the row off the list.
- The event's finance owner enters the actual on the line directly and dismisses the row with a reason. That keeps the row, its reason, and who dismissed it on the event record.
Matching a row. Matching happens two ways in turn, and both end in the same place.
Your ERP sends the invoice again with the correct cost-line reference and in the event's budget currency, and the match runs on the reference by itself.
On a row a confirmed allocation stopped, the invoice is resent after the allocation is reopened, or, if the handoff has already been delivered, after the correcting version is confirmed.
Or you match the row here, by hand. Match to cost line on the row opens the cost lines of this event, and the line you select takes the invoice and settles.
Who holds the controls. Match to cost line belongs to the event's finance owner, the same person the dismissal belongs to.
One named person therefore decides what happens to every row in the view. One row class is never matched by hand.
Nothing is converted on an event budget, so an invoice in a currency other than the event's budget currency has no line that can take it.
The control is unavailable on that row. It leaves the view after a resend in the budget currency, or after the dismissal.
No notification goes out. A row landing in that view does not notify anyone, and no view lists unmatched invoices across events.
You need to read the Unmatched invoices view on the event as part of the reconciliation pass, because nothing announces it.
The connection that delivers them is documented in Connecting finance, procurement, travel, and transparency systems.
What a settled line shows. Each settled line shows its Actual amount and its Invoice reference. The ERP remains the system of record for accounting.
If a final cost has no ERP document, you enter it in the line's Actual amount field directly (see Adding cost lines in Budget capture at request and working the budget during planning).
Cost lines are created, edited, and settled on the event's Budget module in Onomi 360, the module this guide documents. Every amount of the event therefore reconciles in one place.
The Claims view. Beside the Unmatched invoices view, the module has a Claims view. You see the cost lines on this event marked Reimbursement claim, with their claim status.
The same two groups that can edit the budget on this event open it: 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, the finance role opens it alone. Route for reimbursement on those lines remains with the event's finance owner.
It is documented in How to manage payments, honoraria, and reimbursement on your events.
2. Confirm each cost line
Reconcile each line: open it, confirm the landed amount, and select Mark reconciled. The line shows as reconciled, and the Actual column and its roll-ups show what was actually spent.
3. Resolve missing actual costs
Work the lines a blank-cost policy has flagged. At this stage the policy checks the Actual column, from the End date on the event record onward, and on a cancelled event from the cancellation.
The lines it flags here are therefore the ones still with no actual amount, and those are what is outstanding (see Budget policies in Setting up budgets: categories, bands, and policies).
The event cannot close while lines remain unreconciled.
4. Review the hospitality check
Clear the hospitality flag if there is one. As lines are reconciled, the reconciled hospitality spend per person is checked against the meal cap set for the event's market.
What the check divides. What is summed is set by your category hierarchy (see Categories and GL codes in Setting up budgets: categories, bands, and policies).
Onomi adds up the reconciled actuals on every cost line in a category marked Counts toward the meal cap.
It divides that total by the number of attendees who were recorded present and have a registrant type marked transfer of value relevant.
The result it compares with the cap is the event's total hospitality spend per disclosable attendee. It is a per-event per-person figure, not a per-meal or per-day one.
A category left at the default contributes nothing. If no category has the setting, there is nothing to sum and the check does not run.
Which category the setting is read on. The setting is read on the category each cost line is under.
If that is an event-specific sub category added on this event, the value used is the one on its parent main category.
A line under an event-level sub category of a category marked yes therefore still counts.
The divisor. The divisor is the same population shared costs distribute across in the allocation (see Running and correcting an allocation).
Internal staff, agency registrant types, and anyone recorded as a no-show therefore do not enter it.
Public officials. A public official enters it on the same terms as anyone else, meaning only under a registrant type marked transfer of value relevant.
The standard types the registrant-type list arrives with cover healthcare professional, internal staff, and agency types, and none of them is a public-official type.
If your transparency process discloses transfers of value to public officials, the type is added and marked with your SpotMe team.
This happens before the check counts those attendees (see How to manage transfer of value on your events).
Recorded present. Recorded present means the attendance state on that person's row is Show.
An attendee with a row still marked No state recorded is left out of the divisor, exactly as a no-show is.
An attendance record that is only partly recorded divides the same spend across fewer people, and gives a higher figure per person than the event really was.
Check the attendance record first. Confirm the attendance record is complete before acting on the result.
You see the attendees with no state recorded grouped at the top of the Review tab of the event's Transfer of value module, with a count.
The count is zero on a finished record (see Running and correcting an allocation).
You need to read it before you record a reason on a Meal cap exceeded flag, and before you take a check that did not run as a pass.
When there is nobody to divide by. If no attendee recorded present has a registrant type marked transfer of value relevant, there is nothing to divide by.
The check records that the cap did not apply, and no Meal cap exceeded flag is raised.
This is the ordinary outcome on an internal meeting with catering booked to a category marked Counts toward the meal cap while only internal staff and agency registrant types attend.
It is also what an HCP dinner nobody checked in produces, which is the case that count catches.
The currency of the cap. Each market has a currency, and its meal cap is set in that currency. The comparison runs in that currency and nothing is converted.
An event budget is kept in the currency of its request, and is never converted either.
If the two currencies differ, the reconciled actuals and the cap are not compared. The check records that the cap did not apply, and no flag is raised.
Setting each market's currency. Set each market's currency to the one the events in that market are budgeted in.
Split a grouping that spans currencies into markets of its own, so every cap has amounts it can be read against.
The market's currency is set on the Markets list (see Setting up travel and capturing travel needs).
When the figure passes the cap. If the currencies match and the figure comes out above the cap, you see a Meal cap exceeded flag on the event's budget.
It says "Reconciled spend on meal-cap categories is EUR 142 per person, above the EUR 120 meal cap for France. Record a reason or correct the actual." The message quotes that per-event per-person figure, and the market cap it passed.
The per-person figure is the whole event's spend on the categories that count, divided across its disclosable attendees.
The figure in the message is the event's, not the cost of one meal or one day.
A two-day meeting with three catered meals is therefore measured once, on everything in those categories, and not meal by meal.
Who is notified. The notification goes to the recipients of every threshold policy kept in the event's budget currency, if that policy's scope includes a category that counts toward the meal cap.
A policy in that currency with Applies to set to the whole event budget counts too, since a whole-budget policy evaluates every cost line and the event total.
If several policies match, each policy's recipient list is notified once. If no policy in the event's budget currency covers any of those categories, the notification goes to the event's finance owner.
That owner is the person the flag already waits on, and the one who clears it. Either way the exception has an owner from the moment it exists.
The flag is not routed to compliance. The flag is not routed to compliance review.
It notifies and it waits for the finance owner, while an over-cap estimate at request time can route the request to a compliance reviewer.
Organizations that want compliance in the loop on real spend name their compliance reviewers among the notification recipients of a threshold policy that already covers one of those categories.
They do that in each currency their events are budgeted in, since only a policy kept in the event's budget currency counts.
Naming compliance on a threshold policy. If no such policy exists, creating one only to record those names has a side effect to plan for. A threshold policy has a Limit.
It is evaluated every time a cost line is saved, and it triggers on ordinary spend as soon as a value in its scope crosses that limit.
Either set its Limit above anything an event in that currency could have been approved for, so it does not trigger on ordinary spend.
Or leave the finance-owner fallback in place, and have the finance owner bring compliance in when the flag appears.
The limit such a policy needs. Take that 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.
A policy created this way needs notification recipients, because creating it is what removes the fallback.
The fallback applies only if no policy in the event's budget currency has one of those categories in its scope.
A policy with an empty recipient list therefore leaves the flag with nobody to notify on every event budgeted in that currency.
When the check runs. The check is evaluated whenever the reconciled actuals on the counting categories change: on Mark reconciled, which brings that line's Actual amount into the sum, and on a later cost-line save that changes the Actual amount on a line already marked reconciled, whether you enter the amount or an ERP invoice settles the line.
An Actual amount that has landed on a line not yet marked reconciled is not in the sum yet.
Attendance is not a trigger. Completing or correcting the attendance record changes the divisor. It does not re-run the check, and it does not clear a flag that is already standing.
Attendance is recorded outside the Budget module, in the event workspace's Users module or on the event record's attendee list on a meeting with no workspace.
Clearing the flag. You can clear the flag one of two ways. Record a reason on it.
Or correct the Actual amount on the line with the wrong figure, so the per-person figure is back inside the cap.
See Adding cost lines in Budget capture at request and working the budget during planning.
Either way the flag, the reason, and who cleared it remain on the event record.
Meal caps are defined per market with the rest of your venue rules. See Setting venue rules in Onomi 360 for the cap and its request-time check.
Note: This is a different measurement from the request-time check, and the two can disagree without either being wrong.
At request time the comparison is the Estimated hospitality per person stated on the request against the same market cap. At reconciliation the comparison is real actuals over a real attendance record.
The request-time comparison is made before any spend exists and before anyone has attended.
It is a routing input, and it sets the Over meal cap indicator on the request. The reconciliation comparison puts the Meal cap exceeded flag on the event's budget.
The two also differ in where they go. The request-time condition can route a request to compliance review before the meeting happens. The reconciliation flag is not routed anywhere.
Its notification goes to the recipients of every threshold policy kept in the event's budget currency, if that policy's scope includes a category that counts toward the meal cap.
If several policies match, each policy's recipient list is notified once. If no policy in the event's budget currency covers any of those categories, the notification goes to the event's finance owner.
That owner is the person the flag already waits on, and the one who clears it.
A meeting can clear the estimate and exceed the actual. Most often that is because fewer disclosable attendees turned up than were expected. Sometimes it is because the attendance record is not finished.
An attendee with a row marked No state recorded is left out of the divisor, exactly as a no-show is. A partly recorded attendance therefore pushes up the per-person figure the check compares.
Note: A cancelled event reconciles and closes its money the same way as a delivered one.
Cancelled is terminal, so Close event on a cancelled event closes its budget lines and records the closure without changing the status, and reporting and audit filters keep the cancellation.
See From approval to execution and auditing requests for the cancellation flow.
Budgeted and committed amounts remain on the record. Cancellation and no-show costs are captured as actuals through reconciliation: a venue cancellation fee under the award's terms, a cancelled booking's fee, a no-show's cost.
The record keeps the full financial story of the cancellation.
Closing the event
- When every line is reconciled, select Close event on the budget header, and confirm. On a delivered event, the status moves to Closed.
On a cancelled event, Cancelled is terminal: the closure is recorded and the status remains Cancelled (see the Note above).
Closing requires reconciliation to be complete. If you try to close earlier, the action stops with "This event cannot be closed while 3 cost lines are unreconciled." The lines still open are listed under the message, so you can open them from there.
- Per-attendee cost allocation of the reconciled costs runs in the Transfer of value module once reconciliation is complete, before or after the close; see Running and correcting an allocation.
- Export the event's financial record from the event page. There is no separate closure document to produce: the same record set comes off the event's own records, each exported where it is read.
You can export three things:
- The participants and their attendance, from the event record.
- The final budget with actuals and the Invoice reference on each settled line, from the Budget module.
- If the event allocated transfer of value, the confirmed per-attendee allocation, from the Transfer of value module (see Running and correcting an allocation).
You can export as XLSX or CSV.
Producing one is an export, so your organization's classification rules apply to it on the terms they apply to any other export.
A user the Export rule for a record's level does not admit cannot take that export.
If a rule excludes records, the produced file states that an exclusion was applied, the same notice a report gives.
- If the allocation is corrected after you exported it, export it again. This applies to both correction paths. The first is an allocation reopened and confirmed again.
The second is a correcting version confirmed with Correct allocation, once the handoff has been delivered and Reopen is no longer offered (see Running and correcting an allocation).
Each confirmed version remains on the event record, so the export you take after the correction is the one that matches the record.
To verify, open the event record after closing. A delivered event shows the status Closed.
Every cost line shows as reconciled with its actual and its Invoice reference. The exports from the event page include those final numbers.
For how allocated spend feeds transparency reporting, see the Transfer of value release notes.
* Onomi 360 MeetingsEQ exclusive capabilities.
Comments
0 comments
Please sign in to leave a comment.