Connecting finance, procurement, travel, and transparency systems

Use this pattern for enterprise systems that receive a sourcing award, create a purchase requisition or order, return invoices and final costs, work travel requests, route expense claims, or receive disclosure records.

Onomi keeps the event-side operational record. The procurement, ERP, expense, travel, payment, or transparency platform remains authoritative for the business transaction it executes.

Start with a shared matching contract

Every flow needs stable identifiers for the Onomi event and the destination record. Add the cost-line identifier, sourcing-request identifier, attendee or HCP identifier, and country or legal-entity code where the transaction requires them.

Document which side creates each identifier and where the cross-reference is stored. A retry must update the same transaction, not create another requisition, invoice, claim, booking, or disclosure delivery.

Agree currency, tax, general-ledger code, cost center, intercompany code, supplier, and legal-entity rules before field mapping. Do not silently convert or infer a value when the destination requires an explicit accounting decision.

Send a sourcing award to procurement

After a venue award, Onomi can send the award data required by the customer's procurement process. The procurement system, such as SAP Ariba, Coupa, or an SAP procurement workflow, creates and governs the purchase requisition and purchase order.

The outbound contract can include the event and sourcing identifiers, supplier, awarded amount and currency, service dates, market, cost center, category or GL code, contract reference, and supporting documents agreed for the deployment. Onomi stores the returned requisition or purchase-order reference on the event-side record.

Contracting and signature remain in the configured sourcing and signing workflow. For example, a Hubli sourcing process may send the selected contract through DocuSign and return the executed-contract reference; Onomi should not claim ownership of the signature transaction.

See Sending the RFP, comparing bids, and contracting the venue.

Return commitments, invoices, and final costs

The ERP or procurement platform returns the committed or invoiced amount against the stored event and cost-line reference. An amount that matches the event currency and an eligible open cost line can settle against that line according to the configured contract.

Keep Budgeted, Committed, and Actual amounts distinct. A purchase order can supply or update a commitment; a verified invoice or final settlement supplies the actual according to the customer's accounting process.

Handle exceptions visibly

Do not post an invoice automatically when:

• the event or cost-line reference is missing or unknown;
• the invoice currency conflicts with the event budget currency;
• the GL or category mapping does not resolve;
• the amount targets a cost line closed by a confirmed allocation; or
• the invoice would violate another configured accounting or lifecycle rule.

Put it in Unmatched invoices with the source reference and the reason it stopped. An authorized finance user can correct the mapping or record, send the source transaction again, or dismiss the exception with a reason.

A confirmed transfer-of-value allocation closes the actual amounts and attribution it read. Reopen or correct the allocation before applying a replacement amount, following Running and correcting an allocation.

Connect travel and expense systems

Travel requests can be delivered to the internal travel team, travel management company, or connected travel platform selected for the request's market. The destination works the booking and returns the booking reference, status, confirmed itinerary, and cost fields agreed in the deployment.

Keep Onomi's request state distinct from the booking transaction owned by the travel system. A cancellation or itinerary change should carry the original cross-reference and return its updated status instead of creating another request.

For Concur or another expense platform, route a marked reimbursement claim with its claimant, amount, currency, event and cost-line identifiers, attendance evidence, category, and attachments as permitted by the customer's policy. The expense system decides eligibility, approval, and payment, and returns statuses such as approved or paid when the contract includes them.

This pattern can follow the documented behavior of an established Concur integration without claiming identical implementation or feature parity. The exact fields, status values, latency, and error ownership are customer-specific.

See How to manage travel and accommodation for your event and How to manage payments, honoraria, and reimbursement on your events.

Deliver confirmed disclosure records

The transfer-of-value handoff sends a confirmed, country-specific allocation to each configured transparency destination. The customer transparency platform remains the destination system of record for the submitted disclosure process.

Define country coverage, identity keys, category mapping, currency, delivery format, credentials, status callbacks, and correction behavior per destination. A correcting allocation is delivered as a new version that identifies the version it corrects; the earlier handoff remains in the audit history.

An organization can use more than one destination. Track delivery and errors separately per destination while applying the allocation-level correction rule described in The disclosure handoff and accessing allocation data.

Connect payment execution only through an agreed provider

Onomi can capture payment-relevant event data and registration payment results, but it does not replace the customer's ERP payment runs, banking partners, or payment gateway. The provider executes the financial transaction and returns only the status and references included in the contract.

Keep payment credentials out of article configuration and event exports. Store them through the approved secret and provider setup for the deployment.

Define controls for every connection

For each destination, record:

• system-of-record ownership;
• identifiers and idempotency key;
• fields, currencies, and allowed status transitions;
• authentication and secret ownership;
• expected schedule or latency;
• retry and duplicate handling;
• visible exception and reconciliation process;
• audit fields and retention; and
• customer, partner, and SpotMe support ownership.

Test a valid transaction and each material exception. Reconcile event totals and record counts against the destination before production activation, then repeat that reconciliation after any mapping or version change.

For the integration overview, see Integration patterns: connecting Onomi to your enterprise systems.

* Onomi 360 MeetingsEQ exclusive capabilities.