Event Account, Requester & Bill-To Field Standards
Answered
VCET are currently working through some internal data standards around the use of the Event Account, Contact, Requester and Bill-To fields within Momentus Enterprise and would appreciate guidance on the intended product logic and recommended best practice.
The discussion relates to events where multiple organisations may be involved; my understanding has generally been:
- Account + Contact represent the primary event account and relationship owner. Where a PCO is engaged, this would typically be the PCO and their primary contact.
- Requester Account + Requester Contact represents the end client or organisation on whose behalf the event is being delivered.
- Bill-To Account + Bill-To Contact represents the legal entity responsible for the contract and payment.
However, there is an alternative view internally that the Account should always represent the end client or event owner, with the PCO recorded as the Requester.
Before we finalise our internal standards, we wanted to understand both the product perspective and how this is typically implemented across the wider customer base.
What would Momentus recommend as best practice for the use of the Event Account, Requester and Bill-To relationships, particularly where multiple organisations are involved?
-
Tagging a few internal experts on this post Martin Wooding Anthony Costantino Minka Verkaar Samy Kheloufi
-
Philip Bathfield forgive me but what type of venue is VCET? convention center? corporate? exhibition organizer? etc
-
Can you confirm if this is accurate, specifically multi - org: (Source: I ran a command in Gainsight to extract specific emails mentioning bill-to, requester, multi - org)
INTENDED PRODUCT LOGIC
The three fields serve distinct purposes:
- Event Account & Contact: represents the PCO or organising entity; the party managing the event and the primary relationship owner with the venue. Where a PCO is engaged, this should be the PCO and their primary contact. This aligns with industry practice, as the PCO is typically the main point of contact and manages the event on behalf of the end client. Note: Sales AI uses the Event Account and Contact when converting events, so getting this right has downstream system implications.
- Requester Account & Requester Contact: represents the end client; the organisation on whose behalf the event is being delivered. When a PCO is involved, the Requester should reflect the end client or event owner that the PCO is representing.
- Bill-To Account & Bill-To Contact: represents the legal entity responsible for the contract and payment. This may be the PCO, the end client, or another organisation entirely, depending on your contractual arrangements.
On the internal question of whether the Account should represent the end client rather than the PCO — the product is designed with the PCO-as-Account convention in mind, and the Sales AI behaviour further supports this. The recommended approach is PCO as Account, end client as Requester.
MULTI-ORGANISATION BILLING
Where multiple organisations are responsible for different charges: for example, a sponsor covering specific items while the client covers the remainder, the recommended approach is to manage this at the Service Order level rather than the event header. The Bill-To Account and Contact should be set on each relevant Service Order to reflect the correct paying party for those charges. This keeps the event record clean and avoids the need to represent multiple billing entities at the header level.
PRACTICAL POINTS FOR YOUR STANDARDS
A few implementation details worth capturing as you finalise your internal documentation:
1. Reporting configuration: All standard reports draw the Bill-To from the service order, so filtering works correctly in multi-org scenarios. This would only be an issue if you built a custom report — in that case, a Crystal Reports adjustment may be needed to pull Bill-To from the service order level.
2. Billing address validation: for invoices involving subsidiaries or sub-entities, always confirm that the report is pulling the Bill-To Account address rather than the Bill-To Contact address, to ensure the correct legal entity address appears on the invoice.
3. Troubleshooting unexpected organisations: If an organisation is appearing on a report unexpectedly, check the following fields: Main Account, Requester Account/Contact, Bill-To Account/Contact, and all related Orders and Service Orders.
-
I sent the above to the customer and she was happy, no further action needed unless there is more to add.
Please sign in to leave a comment.
Comments
4 comments
Date Votes