Reconciliation, invoices, and closing the event

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 covers clearing the meal-cap and unmatched-invoice work, and 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. That person is 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, through 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 rather than 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, rather than waiting for reconciliation.

The Finance owner field is 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 reconciliation check raises a Meal cap exceeded flag where no threshold policy kept in the event's budget currency covers any category that counts toward the meal cap.

The refused sourcing-award write is a set of states rather than a single one. Four states refuse the automatic write:

• An award currency differing from the event's budget currency.
• A budget header carrying no band and no budget currency.
• No category carrying 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).

1. 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 whose scope covers this event and nobody else, so the grant comes first. Assign the role in Onomi 360 > Users and roles with a scope that covers the event, then name the person here. Setting the field is the work of a holder of the finance role whose scope covers the event, or of 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.
2. 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 while the closure has not been recorded, whether or not the budget carries 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. So a meeting that spent nothing and a budget whose lines are all reconciled are 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 reads the End date there rather than anything held in a workspace. An event with no workspace, a record-only meeting from a category mapped to record-only, therefore carries 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. That is the same setting the approval reminders follow, 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. So an administrator cutting approval-email noise does not silence the closure driver on the highest-volume lane.

   The 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 that reaches, 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 is held rather than sent elsewhere.

The budget header shows a Finance owner not set indicator, and the held notifications go out as soon as an owner is named. The Reconciliation reminder stands on the same footing. The event's finance owner is its only default recipient. So while the field is empty the reminder is held rather than sent elsewhere, and it goes out as soon as an owner is named.

That reminder is the only thing driving a record-only meeting to closure. So an organization running record-only categories at volume names the owner as each record is created. No meeting on that lane then sits with the field empty and its reminder held. That is why the field belongs at approval rather than at closure.

Note: The assignment carries the controls that come with it: 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 covers the event, the change takes effect immediately. Those controls stop resolving for them, while everything they already did stays 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 with every line confirmed.

1. Final costs and invoices land against the event record from the ERP, settling the cost lines they belong to. That is how an invoice arrives: your ERP sends it, and it is matched on the cost line's own reference. That reference is the value the commitment carries out to the ERP and the invoice quotes back. There is no upload control on the module, and nobody keys an invoice in by hand. Where a final cost has no ERP document at all, the event's finance owner enters the actual on the line directly instead. That is the manual path and the only one.

   How the match runs. The invoice carries 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. That invoice is recorded against the event as unmatched and read in the event's Unmatched invoices view, rather than settling the wrong line or creating one.

   An invoice in another currency. An event budget is kept in one currency, and nothing is converted. So an invoice whose currency differs from the event's budget currency is 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 carrying a GL code no category in your organization's hierarchy holds 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 raises no notification. It settles in one of three ways:

   • The invoice is resent carrying a code your hierarchy holds, together with the reference of the line it settles.
   • The event's finance owner matches the row to the line with Match to cost line.
   • That owner enters the actual on that line and dismisses 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 read 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 raises no notification. 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. Every invoice the match refuses lands in the Unmatched invoices view on the event's Budget module. Each row carries the invoice reference, the settled amount and its currency, the invoice date, and the value that failed to match. A row clears in one of two ways:

   • The invoice is matched to the cost line it belongs to. That 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 resend follows the reopening, or the confirming of the correcting version where the handoff has already been delivered. Or the row is matched 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. That control belongs to the event's finance owner, the same person the dismissal belongs to. So one named person 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 whose currency differs from the event's budget currency has no line that can take it. The control is unavailable on that row. It clears by a resend in the budget currency or by the dismissal.

   No notification is raised. A row landing in that view raises no notification, and no view lists unmatched invoices across events. So the event's finance owner reads the Unmatched invoices view on the event as part of the reconciliation pass, rather than waiting for it to be announced. The connection that delivers them is documented in the ERP cost and invoice sub-pattern of Integration patterns: connecting Onomi to your enterprise systems.

   What a settled line carries. Each settled line carries its Actual amount and its Invoice reference. The ERP stays the system of record for accounting. Where a final cost has no ERP document, the finance owner enters 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 capture surface this guide documents. So every amount of the event reconciles in one place.

   The Claims view. Beside the Unmatched invoices view, the module carries a Claims view. It lists the cost lines on this event marked Reimbursement claim, with their claim status. The same two groups that hold the budget's per-event writes open it. Those are 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 opens it alone. Route for reimbursement on those lines stays with the event's finance owner. It is documented in How to manage payments, honoraria, and reimbursement on your events.

2. 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 read what was actually spent.
3. Work the lines a blank-cost policy has flagged. At this stage the policy reads the Actual column, from the End date on the event record onward, and on a cancelled event from the cancellation. So the lines it flags here are the ones still carrying no actual amount. That is what is outstanding (see Budget policies in Setting up budgets: categories, bands, and policies). The event cannot close while lines remain unreconciled.
4. Clear the hospitality flag if one is raised. 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). The check divides the reconciled actuals on the cost lines whose category is marked Counts toward the meal cap by the attendees recorded present whose registrant type is marked transfer of value relevant. The figure it compares with the cap is therefore the event's total hospitality spend per disclosable attendee. That is a per-event per-person figure, rather than a per-meal or per-day one. A category left at the default contributes nothing. Where no category carries the setting there is nothing to sum and the check does not run.

   Where the setting is read. The setting is read on the category each cost line sits under. Where that is an event-specific sub category added on this event, 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.

   The divisor. The divisor is the same population shared costs distribute across in the allocation (see Running and correcting an allocation). So internal staff, agency registrant types, and anyone recorded as a no-show 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. So where your transparency process discloses transfers of value to public officials, the type is added and marked with your SpotMe team. That 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 reads Show. An attendee whose row still reads No state recorded sits outside the divisor, exactly as a no-show does. An attendance record that is only partly recorded divides the same spend across fewer people, and reads higher per person than the event really was.

   Check the attendance record first. Confirm the attendance record is complete before acting on the result. The attendees with no state recorded are grouped at the top of the Review tab of the event's Transfer of value module, with a count. That count reads zero on a finished record (see Running and correcting an allocation). 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.

   Where there is nobody to divide by. Where no attendee recorded present carries 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. That is the ordinary outcome on an internal meeting whose catering books 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 carries 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. Where 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 it covers 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).

   Where the figure passes the cap. Where the currencies match and the figure comes out above the cap, the event's budget carries a Meal cap exceeded flag. It reads "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. So a two-day meeting with three catered meals is measured once, on everything those categories carry, rather than meal by meal.

   Who is notified. The notification goes to the recipients of every threshold policy kept in the event's budget currency whose scope covers a category that counts toward the meal cap. That includes a policy in that currency whose Applies to is the whole event budget, since a whole-budget policy evaluates every cost line and the event total. Where several policies match, each of their recipient lists is notified once. Where no policy in the event's budget currency covers any of those categories, the notification goes to the event's finance owner, who is the person the flag already waits on and 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, where 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 is read.

   Naming compliance on a threshold policy. Where no such policy exists, creating one only to hold those names has a side effect to plan for. A threshold policy carries a Limit. It is evaluated every time a cost line is saved, and it fires 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 stays quiet on ordinary spend. Or leave the finance-owner fallback in place, and have the finance owner bring compliance in when a flag is raised.

   The limit such a policy carries. 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. A policy held that way has to carry notification recipients, because creating it is what removes the fallback. The fallback fires only where no policy in the event's budget currency covers one of those categories. So a policy standing with an empty recipient list 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 a person enters 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. The flag clears one of two ways. The finance owner records a reason on it. Or that owner corrects the Actual amount on the line that carried 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 stay 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 writes the Over meal cap indicator on the request. The reconciliation comparison raises 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 routes nowhere. Its notification goes to the recipients of every threshold policy kept in the event's budget currency whose scope covers a category that counts toward the meal cap.

Where several policies match, each of their recipient lists is notified once. Where no policy in the event's budget currency covers any of those categories, the notification goes to the event's finance owner, who is the person the flag already waits on and 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 whose row reads No state recorded sits outside the divisor, exactly as a no-show does. So a partly recorded attendance raises 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 stay 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

1. 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 stays Cancelled (see the Note above). Closing requires reconciliation to be complete. Attempting to close earlier stops with "This event cannot be closed while 3 cost lines are unreconciled." The lines still open are listed under the message, so they can be opened from there.

2. 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.
3. 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.

   Three things export:

   • 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.
   • Where the event allocated transfer of value, the confirmed per-attendee allocation, from the Transfer of value module (see Running and correcting an allocation).

   Exports are XLSX or CSV.

   Producing one is an export, so your organization's classification rules reach it on the terms they reach any other export. A user the Export rule for a record's level does not admit cannot take that export. Where a rule excludes records, the produced file states that an exclusion was applied, the same notice a report carries.

4. If the allocation is corrected after you exported it, export it again. That covers 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 stays on the event record, so the export taken 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 reads as reconciled with its actual and its Invoice reference. The exports from the event page carry those final numbers.

For how allocated spend feeds transparency reporting, see the Transfer of value release notes.

* Onomi 360 MeetingsEQ exclusive capabilities.