Client Processing and Deal Engine: Integration Overview for Upstream Systems
Purpose and Audience
This document is written for the IT owners and power users of the systems that sit upstream of UTA's Client Processing and Deal Engine — the departmental CRMs, the agent and assistant tools, the booking systems, and any internal apps that originate or manage the relationship between an agent, a client, and a buyer. It is not written for the finance, cash, or accounting users who operate Client Processing day to day.
The goal is to give you a complete picture of:
- The data elements you will exchange with the Deal Engine and Client Processing
- The shape of the conversation between systems (push, pull, events, status)
- The features and workflows your users can take advantage of (directly or by building it into your own UI)
- The points where Client Processing surfaces information back into the agent/CRM world that you will want to consume or display
We will go into detail on data structures like Sales Items, Payment Terms, and Deals because they are the contract between your system and ours. We will not go into detail on how Client Processing internally moves money, books revenue, or builds journals — that is intentionally hidden behind APIs.
For deeper dives into any specific topic, links to the underlying documentation are included throughout.
Sources of truth: Deal Engine sits between your CRM and Client Processing. Authoritative master data (parties, organizations, etc.) comes from a separate system documented at the Authoritative Data registry. Anything related to GL posting flows on through a separate General Ledger Interface.
Where Client Processing Sits in the Client Framework
The Client Framework is the umbrella for all of UTA's marketplace software. The four major pillars are:
| Pillar | Role |
|---|---|
| Authoritative Data | The master record for clients, buyers, agents, organizations, and other parties |
| Deal Engine | Stores and computes the financial terms of agency transactions as deals evolve |
| Client Processing | Operates the receivables, cash, settlements, payments, AR, and revenue recognition for those deals |
| General Ledger Interface | Translates Client Processing activity into entries for NetSuite |
From a CRM's point of view, the Deal Engine is the front door. You write deals into it, you ask it about deal status, and you receive notifications back from it. Client Processing is largely downstream of the Deal Engine — it consumes deal data, runs the cash and settlement lifecycle, and feeds status events back through the Deal Engine. Nothing prevents a CRM from talking to Client Processing directly through APIs (in fact, several useful integrations require it), but the bulk of the deal-data conversation happens through the Deal Engine.
The visual stack from a CRM's perspective:
TODO - Add Diagram
Reference: Client Processing Overview, Deal Engine Overview.
Part 1 — The Core Data Elements
The communication between the Deal Engine, Client Processing, and the CRMs is built around three core data elements, plus a fourth flexible block. These are the things you will create, send, update, and inquire about. If you understand these four constructs, you understand the API.
1.1 The Deal
A deal is the lightest of the three. It is a grouping construct, nothing more. The deal does not carry the financial detail; it carries identity, parties, and dates. It is where the sales items live.
Required attributes:
- A name (free text, descriptive — e.g. "2026 Eras Tour – Stadium Block")
- A deal reference (auto-generated if you do not provide one — pattern
DEAL-{random}) - A start date and end date (the active window of the deal)
- A list of parties (each with a role: client, buyer, agent, attorney, manager, business manager, etc., plus commission terms and bank routing as applicable)
Critically, a deal can group sales items in any way that makes sense for the department. There is no rigid hierarchy. One deal can contain one sales item or many; one client can be on multiple deals; one buyer can buy across many deals. Unlike a "booking" in legacy systems, a deal is not bound to a single buyer or a single client.
Reference: Deals Workflow.
1.2 The Sales Item
The sales item is the unit of work — the performance obligation that the client owes. It is the thing UTA gets paid for. Examples:
- A guarantee for one term year of a TV contract
- An overage above a guarantee
- A speaker fee for a single event
- A book advance
- A licensing fee for one territory
- A commercial endorsement minimum
- A placeholder for a not-yet-known bonus
Required attributes:
- A UTA entity / subsidiary (which UTA legal entity is invoicing)
- A department (Talent, TV Lit, Music, Touring, Sports, Speakers, etc.)
- A client (the artist/talent/creator)
- A contract party / loanout (often the same as the client, sometimes a corporation)
- A buyer (who is paying)
- A gross amount and a commission amount (the commission can be zero for placeholder or pass-through items)
- A commission type — percentage (
P) or flat (F) - Revenue start and end dates plus a recognition style (Immediate, Monthly, or Cash-based)
- Status flags (more on these in Part 4)
A sales item can be a placeholder. A bonus or overage that may or may not happen can sit as a sales item with estimated or zero amount and an unconfirmed status, ready to be filled in if the event occurs.
Reference: Deal Engine Structure and API — Section 1.1.
1.3 The Payment Term
The payment term describes how cash will be received against a sales item. Where the sales item is the what and total amount, the payment term is the how much we receive and when.
Required attributes:
- A reference to its parent sales item
- A gross amount (this is the buyer-side amount for that installment)
- A due date with a due date status (confirmed or estimated)
- A payment party (typically the buyer, but can be the client — see "collection style" below)
- A name (e.g. "Installment 1 of 4," "Q1 2026 advance")
The hard rule: the sum of all payment terms on a sales item must equal the gross and commission of the sales item to the cent. The Deal Engine will reject a sales block that does not balance.
Payment terms can be auto-generated by the Deal Engine if you specify a schedule type — Immediate (I), Weekly (W), Monthly (M), Quarterly (Q), Annual (Y), or Custom (C). For non-custom schedules, the engine spreads the gross across the date range and absorbs penny rounding into the last installment so the totals still tie out.
A useful corollary: a four-quarter guarantee with a single $1M sales item produces four payment terms of $250K each. A one-shot speaker fee is one sales item with one payment term. A back-end-loaded TV deal is one sales item with N payment terms across N weeks/months.
Reference: Deal Engine Structure and API — Section 1.3.
1.4 Metadata
The fourth (and optional, and unbounded) element is metadata. Metadata is anything else you want to attach to a sales item or deal that is not part of the financial contract. The classic examples:
- Agent attribution — booking agent, responsible agent, agent team, allocation percentages
- Project / show / book / work — the artistic project the sales item relates to
- Territory / service location — for tax and reporting
- Internal codes — your CRM's own tracking IDs
Metadata is intentionally outside the core transaction model in Client Processing. It is stored as type/value pairs (e.g. metaDataTypeCd = 'PROJECT_NAME', metaDataValue = 'Top Gun 3'). You can ship as much or as little as you want, and the schema can vary by department. Client Processing does not enforce what you send — it stores it, exposes it on screens, and makes it available for reporting.
This is also the right place to send anything your CRM users will want to see when they look at billing, AR, or settlement screens later. If your users will ask "which agent gets credit for this?" — that lives in metadata. If they want to ask "what tour stop does this revenue tie to?" — that lives in metadata or can stay in the CRM and be linked by sales item ref.
Reference: Deal Engine Structure and API — Section 1.2, Functional Approach – Avoid Metadata on Transactions.
1.5 The Reference Pattern
Every deal, sales item, and payment term gets an immutable reference:
deal_reference(e.g.DEAL-XYZ123)sales_item_ref(e.g.REF-ABCD12)payment_term_ref(e.g.TERM-A)
These references are auto-generated, and once generated they live forever. All conversation between your system, the Deal Engine, and Client Processing should be keyed on these references. Internal database IDs (sales_item_id, etc.) change as records get versioned; the references do not.
This is the single most important integration concept in the whole framework. Store these references in your CRM. Search by them. Send them on every update or inquiry. They are the equivalent of a booking number in legacy systems but far more powerful, because they survive every change.
1.6 Versioning and Immutability
The second concept that follows from references: nothing is ever updated in place. Every change creates a new version of the deal, sales item, or payment term. The reference stays the same; the version number ticks up; the previous version is preserved.
This means:
- The full history of a deal — every change to amount, date, party, status — is intrinsic to the design. There is no separate audit log to query.
- Forecasts, reports, and reconciliations can be reproduced as of any prior date.
- "Reverse and replace" is the default mutation pattern. If you tell us the gross changed, we don't overwrite the old gross — we close out the old version (with offsetting entries downstream where necessary) and create a new one.
For your system: when you fetch a sales item, you may want to fetch by sales_item_ref and ask for the current version, or fetch all versions for audit display. The API supports both.
References:
- Functional Approach — Immutability
- Deals Workflow — 3.6 Sales Block Creates New Pipeline Rows on Every Version
1.7 Master Data Carried on Every Transaction
A subtle but important design decision: the core master data fields (uta_entity_id, department_id, client_id, buyer_id, deal_id) are duplicated on every transaction record in Client Processing. This is intentional. It means:
- Transactions can be grouped any way you want without parent/child constraints (e.g., a single billing item can be cross-departmental; a deal does not have to have exactly one client).
- Org changes (a department is renamed, two UTA entities merge) can be handled with a careful data fix rather than a data model change.
You don't need to do anything special with this — just be aware that when you ask Client Processing for transactions, you will get the deal/client/buyer/department on every row, and that data is the snapshot at the time of the transaction.
Reference: Functional Approach — Duplicate Master Data on Core Transactions.
Part 2 — The Deal Engine
The Deal Engine is best thought of as two things in one: a clause library for building deals, and an event engine for tracking everything that triggers variable compensation.
2.1 The Clause Library
Every commercial term in a contract can be expressed as one or more clauses drawn from a library. Examples:
- "Guarantee with quarterly payments"
- "Overage at 5% above gross box office of $X"
- "Royalty per unit shipped"
- "Bonus on signing"
- "Bonus on delivery of episode N"
- "Profit participation"
- "Per diem"
The clause library is centrally maintained. When your CRM constructs a deal, it generally does so by selecting clauses and supplying their parameters (amounts, dates, thresholds, parties). Each clause has a defined output: it knows how to produce sales items and payment terms.
If a financial term comes up in a contract that the existing library cannot represent, a new clause must be added to the library. The goal of the library is to be complete enough that the vast majority of business cases are covered, but not so granular that every individual clause is a one-off. The clause library is a living artifact and you should expect it to grow.
For CRM IT: the clause is your composition unit. Your deal-entry UI will likely surface clauses, not raw sales items, because a clause is what an agent or contracts attorney is thinking about. Your CRM passes the clause selection and parameters; the engine returns the resulting sales items and payment terms with their references.
Reference: Deal Engine Capabilities, Deal Modeling.
2.2 Deal States and Clause States
Deals are immutable and stateful. Like sales items and payment terms, every change to a deal creates a new version of the deal that represents the holistic current state. Deals can carry multiple states simultaneously when needed — for example, a draft state and an active state — but the typical flow is draft → active → closed.
Each clause within a deal also carries its own state. The two most important clause states for our integration are confirmed and unconfirmed:
- Confirmed — the clause is the final word. Revenue can recognize against it. Billing items can be created. Cash can apply to it.
- Unconfirmed — the clause is a best estimate. The deal can still forecast against it, and it appears on screens, but no revenue is recognized.
This is the lever for variable comp. An agent or assistant can put their best estimate into a variable clause (say, "$50K bonus on box office threshold") and leave it unconfirmed. Forecasting includes it; revenue does not. When the actual amount is known, the clause is updated and confirmed in one motion. Revenue catches up automatically in Client Processing.
Reference: Deal Engine Overview, Deals Workflow — Status Behavior.
2.3 Placeholder Clauses
A particularly useful pattern: a clause can be created with a zero or low value as a placeholder. Examples:
- A box office overage where the deal team does not believe the threshold will be hit, but the clause must exist
- A weekly overtime clause on a long-running production where most weeks do not exceed the threshold
- A "to be negotiated" extension fee
The placeholder lives in unconfirmed status with whatever amount is best-guess (often zero). If and when the trigger event happens, the responsible party — agent, assistant, sales op, AI agent, or another system — locates the clause and creates value against it. For a recurring event (the OT example above), each instance creates a new sales item against that placeholder clause.
This is a major behavioral change from how most systems work today. Today these terms often live in someone's head or in a contract PDF, and the revenue is only captured when a check arrives. The placeholder pattern flips that: the obligation is in the system, and the revenue is captured when the event occurs, not when the cash arrives.
2.4 The Event Engine
Inside the Deal Engine sits a long-running to-do list called the event engine. Every contractual event that drives variable compensation lives here:
- A signing
- An episode delivery
- A theatrical release
- A box office milestone
- A statement period close
- Free throws made above a threshold
- Books sold over a threshold
Each event is created with an estimated date, a description, and a tie back to one or more clauses. Events live in unconfirmed state until either:
- The event happens, in which case someone (a user, an automation, an AI agent, an external API) flips it to achieved
- The event explicitly does not happen, in which case it is flipped to missed
- The estimated date arrives without confirmation, prompting a reminder to update status or date.
When an event flips to achieved, the linked clause produces (or finalizes) sales items and payment terms automatically, and Client Processing is signaled to bill or recognize the resulting revenue. When an event is missed, the linked unconfirmed sales items can be removed or zeroed out.
For your CRM:
- You can create events from your UI when an agent enters a contract clause
- You can monitor open events and surface them on agent dashboards (for sign-off, for follow-up)
- You can confirm or miss events through the API
- You can listen for event-driven sales item creation to update your own pipeline view
This is also where AI is most likely to plug in — IMDbPro, Studio System, Box Office Mojo, and similar feeds can confirm events without human intervention.
Reference: 02. Deal Management, in particular sections 02.02 and 02.03 on milestone monitoring and performance recording.
Part 3 — The Four Interaction Models
The conversation between the CRM, the Deal Engine, and Client Processing is not one-way. We have identified four primary interaction patterns but expect additional variants or more to be added. Most departments use a mix of these.
3.1 Model 1 — Simple Guarantees
The cleanest case. A deal is signed. The compensation is fully known. There are no contingent terms, or the contingent terms are out of Client Processing's scope.
Flow: CRM creates the deal, sales items, and payment terms via the Deal Engine. Client Processing receives them, creates billing items, schedules revenue recognition, and waits for cash. When the buyer pays, cash is applied; settlement runs; participants are paid; the deal is done.
This covers a large fraction of typical talent and lit deals.
3.2 Model 2 — Royalty / Statement-Driven
The amount due is unknown until a statement arrives. This is common in publishing royalties, ad sales for creators, profit participation, music mechanicals, and many endorsement deals.
Flow: The deal is created with a structure that anticipates statements (e.g., a placeholder sales item for "Q1 2026 royalty"). Statements arrive, typically into Client Processing's cash or AR team. The statement is processed in Client Processing — the actual sales item amount is determined, payment terms are written, and the Deal Engine is notified that the placeholder clause has produced a real value. Revenue recognizes; cash applies; settlement runs.
The thing to notice: in this model, Client Processing is the originator of the financial detail, not the CRM. The CRM may want to listen for the resulting sales item creation so it can display royalty performance to the agent, but it does not write the sales item itself.
3.3 Model 3 — Highly Event-Driven
Variable or event-driven revenue applies here. Episode delivery bonuses, contract option bumps, NBA game-bonus clauses, theatrical release milestones.
Flow: The deal is structured with mostly unconfirmed clauses or dates tied to events. Sales items might be billed in unconfirmed status and sit dormant in Client Processing for long periods. The event engine drives everything. When an event achieves, sales items confirm and bill; when an event misses, the corresponding sales items are removed or zeroed out.
The CRM, Client Processing, a user, an external feed, or AI is responsible for telling the event engine that an event happened (or didn't). Client Processing reacts to the messages.
3.4 Model 4 — Mixed (Publishing-Style)
A common pattern: an upfront advance plus ongoing royalty statements, with sales reporting (units sold, format breakdowns, territories) that the CRM wants to display to the agent.
Flow: The CRM writes the advance as a confirmed sales item with one or more payment terms (Model 1 behavior). The royalty side is structured as placeholder clauses (Model 2 behavior). When statements arrive, Client Processing fills them in and notifies. The unit-sales reporting flows from Client Processing back to the CRM as metadata or via report APIs so the agent can see the publishing performance.
This is the most data-rich model from a CRM-display perspective. The important thing to note here is that the statements contain a mix of financial data that Client Processing needs and business insight data that the CRMs need. Wherever the statements are processed, the data needs to be shared between the parties.
3.5 Deal Engine as Registry
Across all four models, the Deal Engine is the registry. Every change to anything financial happens in the scope of a deal_reference, sales_item_ref, or payment_term_ref. The engine knows what version you are talking about; it serializes changes; it routes notifications.
The corollary for the CRM: you do not need to model deal versioning yourself. Send the engine your reference and the change you want to make. It will produce a new version, hold the prior one, and tell Client Processing.
Reference: Deals Workflow — Process Overview and Three-Layer Validation.
Part 4 — Status and Confirmation
There are three statuses that significantly change system behavior. Understanding them is required for any CRM that wants to drive deals through to revenue.
4.1 Sales Item Status (Confirmed / Unconfirmed)
This is the master switch on revenue recognition.
- Unconfirmed — the sales item is a draft, an estimate, or otherwise not final. It appears on screens. It contributes to forecasts. It does not recognize revenue. It does not drive billing.
- Confirmed — the sales item is final. Revenue recognizes (according to its recognition style). Billing items are created in Client Processing.
Toggling between confirmed and unconfirmed will create or reverse revenue automatically. There is no separate revenue button to push.
4.2 Sales Item Date Status (Confirmed / Unconfirmed / Missed)
This applies to the dates on the sales item, not the amount. It is most relevant for event-driven items.
- Unconfirmed — the date is a best-guess (e.g., "we expect delivery in four months").
- Confirmed — the date is the actual date the event occurred or will occur.
- Missed — the event did not happen. Revenue is not recognized.
For long-running revenue recognition (a multi-month or multi-year deal), the start date is what gets confirmed first. The end date is adjusted as the obligation actually completes, at which point the recognition schedule is finalized. This is what you tell sales ops and account teams to review periodically — not the amounts (those are negotiated), but the dates that drive when revenue lands.
4.3 Payment Term Due Date Status
Independent from the sales item date status. The due date on a payment term can also be confirmed or unconfirmed. A payment term whose due date is unconfirmed shows on AR but is not yet aged for collections.
4.4 What This Means for Your CRM
- Encourage your users to enter unconfirmed estimates rather than wait for everything to be final. The forecast value is huge. The downside is zero — unconfirmed items don't generate accounting noise.
- Provide a path in your UI for someone to promote unconfirmed → confirmed with one action.
- Surface the date status prominently. It is the field most likely to drift between systems if no one looks at it.
- Listen for status changes in Client Processing. A finance user can change status from their side too (for example, when a statement arrives that confirms an estimate). Your CRM should reflect the current state.
References:
- Billing Items Workflow — 3.7 Tax Deductions Are Estimates at Creation; Authoritative at Worksheet Time
- Functional Approach — Code Types with Attributes
Part 5 — What Upstream Systems Can See and Do
A core benefit of the Client Framework is real-time visibility for your users. Anything Client Processing knows, your CRM can ask. The expected pattern is that you build inquiry features into your CRM screens — a deal page, a client page, a buyer page — and call Client Processing APIs to populate them.
5.1 What You Can Inquire About
| Domain | Examples of what you can pull |
|---|---|
| Deals | Current state of any deal by reference; full party list; all sales items and payment terms; version history |
| Sales Items | Current sales item; recognition schedule; revenue recognized to date; status; history |
| Payment Terms | Current payment term; invoiced status; amount paid; balance |
| Billing Items | Open AR; aging buckets; balance per receivable; deductions; tax estimates |
| Cash Receipts | Pending cash applied to your deals; unidentified cash that might belong to your client |
| Invoices | Status (Draft, Issued, Paid, Voided); PDF download |
| Statements | All generated statements for a client or deal; PDF download |
| Settlements | Pre-settlement detail; participant breakdown; commission summary |
| Payments | Outbound payments queued, in flight, sent, paid, or held; bank reference; expected date |
| Tasks / Assignments | Tasks routed to a person or agent team; due dates |
| Write-offs | Pending write-off requests; status; approver; amount |
| Tax Forms | 1099-NEC, 1042-S, FEU1/FEU2 form data and PDFs (read-only in CRM) |
5.2 What You Can Do
| Action | Channel |
|---|---|
| Create / update a deal | Deal Engine API |
| Create / update / split / remove a sales item | Deal Engine API |
| Create / update / remove a payment term | Deal Engine API |
| Confirm / miss an event | Event Engine API |
| Confirm a sales item or its dates | Deal Engine API |
| Request an invoice | Client Processing Invoicing API |
| Request a statement | Client Processing Statements API |
| Request a write-off | Client Processing Write-Offs API (with approval routing) |
| Approve a write-off (agent side) | Client Processing Write-Offs API |
| Release / hold an outbound payment | Client Processing Payments API |
| Place a "do not send" hold on a settlement | Client Processing Payments API |
| Claim a cash receipt with client/deal/buyer | Client Processing Cash Receipts API |
| Acknowledge a notification | Notification API |
| Attach a contract or supporting document | Documents API |
The principle: any place in the legacy world where an agent or assistant emailed accounting to ask for something — request an invoice, hold a payment, write off an old AR item, send a statement — should be replaced by an API call from your CRM. If not possible, a portal can be created. The communication is now structured, tracked, and auditable.
5.3 Authentication and Authorization
Work in Progress — Authentication and Authorization are still being defined.
Every API call is authenticated and authorized. A user can only inquire about and act on items they have access to. Access is driven by:
- The user's role (agent, assistant, sales ops, finance, etc.)
- The user's department or agent team affiliation
- The client or deal's confidentiality settings (note: per the new design, all deals are treated as confidential — the legacy "extra confidential" flag is retired)
For service-to-service calls from your CRM, you will use a service principal whose access scope is set at the service level. You do not need to re-implement UTA's permission logic in your CRM — you just respect the access response.
Reference: Client Processing Scope and Capabilities — Permission and Access.
Part 6 — Invoicing
Invoicing is one of the biggest behavioral changes from the legacy world. It is worth understanding deeply.
6.1 What's Different
In the legacy world (and in NetSuite directly), invoicing is tightly coupled to revenue. An invoice has to exist before revenue can be recognized. One invoice clears via one payment. Agent teams email accounting asking for invoices, accounting drafts them, sends them, and chases the buyer. Sometimes agent teams just create their own invoices in Word and email them out, which then bounces back as a number that doesn't match anything.
In Client Processing:
- Invoicing is decoupled from revenue recognition. Revenue recognizes from confirmed sales items on the recognition schedule, regardless of whether an invoice was sent.
- Invoicing is a document feature. It is for sending paper to a buyer or client. Nothing financial depends on it.
- Invoices are flexible. An invoice can include one billing line, many billing lines across multiple deals, or multiple bookings rolled up — whatever the buyer needs to see.
- Adjusting an invoice does not touch the GL. Reissue, void, edit — none of it has financial side effects.
6.2 Where Invoices Come From
Three sources, all legitimate:
- System-generated — when a billing item is created and the buyer's profile says "send invoices automatically"
- Finance-initiated — a Client Processing user generates an invoice from the Invoicing screen
- Agent / CRM-initiated — your CRM calls the API or sends the user to the Client Processing portal
For (3), this is the key replacement for the email-and-ask workflow that exists today. Your CRM can offer a "request invoice" button on a deal or sales item. The API takes the deal/sales item references, the buyer/client recipient, optional template selection, and any notes. Client Processing produces the invoice, distributes it (via the buyer contact on the booking), and reports back the invoice number. If not possible, a portal can be created.
6.3 What Your CRM Should Do
- Add an "invoice" button at the right places (deal page, sales item, buyer page)
- Display invoice status (Draft, Issued, Paid, Voided) on those same pages
- Provide a link or download for the PDF
- For UK and certain other jurisdictions, surface VAT on the invoice request UI
- Surface "days since invoiced" so the agent can see how stale an invoice is
Critically — stop generating invoices outside of Client Processing. Every invoice should originate inside or via the API. This eliminates the "phantom invoice" problem where buyers reference numbers that nothing recognizes.
Reference: Invoicing Workflow.
Part 7 — Statements
Closely related to invoices, but distinct: statements are summaries sent to a client, a buyer, or another party. They roll up multiple receivables, payments, settlements, or other transactions for a defined period.
Statement types Client Processing supports (more can be made):
| Type | Audience | Purpose |
|---|---|---|
| Client Statement | The artist/talent | Summary of all activity (commissions, payments, deductions) for the client over a period |
| Settlement Statement | The client and participants | Per-settlement breakdown showing how cash was split |
| Settlement Statement Detail | The client and participants | Same purpose, sales-item scoped, with finer detail |
| Deal Statement | The client | All revenue items and receivables under one deal |
| AR Aging Statement | Client teams or buyers | Aged AR for collection follow-up |
Statements can be generated three ways: by the system on a schedule, by a finance user on demand, or by your CRM via API. The output is a PDF stored in S3, available via a download link.
For your CRM: a "generate statement" action that takes a client and a date range is a useful agent-facing feature. The agent's perennial question is "what has happened on this client this quarter?" — a statement on demand answers it.
Reference: Statements Workflow.
Part 8 — Cash Application Visibility
Cash receipts (incoming money) are processed in Client Processing, but the agent and assistant teams have a meaningful role to play.
8.1 The Visibility
Every incoming cash receipt — wire, ACH, check, credit card, in any accepted currency — is visible in Client Processing within minutes of hitting the bank. We pull from the banking platform throughout the day. Each receipt has an amount, a deposit date, a remittance memo, and (as we work it) a set of references that tag what client, deal, buyer, or department it relates to.
Some receipts cannot be auto-matched. A wire arrives with no remittance, an ACH lands with the wrong reference, a check has only a buyer name. Today these go on a list for the cash team to research, and they often email agents asking "is this yours?"
In Client Processing, that list — the unidentified cash queue — is exposed to agents and assistants directly through the API. Your CRM should surface a "cash that might be yours" dashboard for each agent team.
8.2 What Agents Can Do
When an agent or assistant recognizes a payment as belonging to a client they cover, your CRM can let them tag it:
- Add a client reference to the receipt
- Add a deal reference to the receipt
- Add a buyer reference to the receipt
- Add a department reference
- Add a sales item reference or payment term reference if known
- Add a free-text note
These tags are not the cash application itself — the cash team still does the formal apply on a worksheet. But the tags massively reduce research time and feed into the matching algorithms.
8.3 Notifications Back to the CRM
When cash is applied to a deal you are watching, Client Processing notifies. Your CRM can subscribe and update the agent's view (e.g., "This deal moved from 50% paid to 75% paid").
Reference: Cash Receipts Workflow, Cash Matching Workflow.
Part 9 — Payments and Settlements
Payments going out of UTA are also significantly redesigned, and your CRM has hooks here too.
9.1 Settlement = Splitting
In the new model, settlement is just the mathematical split of incoming cash among participants. It is not the act of cutting a check. The settlement says "of this $500K we received, $50K is UTA commission, $450K goes to the client (or 80% to client, 10% to the manager, 10% to the lawyer, etc.)." Settlements are computed off the deal party setup and the cash applied.
9.2 The Payment Layer
After settlement comes the payment layer — the actual scheduling and release of money to a participant's bank account. This is where holds, scheduling, and grouping happen.
A payment item, once a settlement is approved, can be in one of these states:
- Waiting — the payment date is in the future or someone has placed a hold
- Pending — ready to send
- Processing — locked, transmitting to the bank
- Sent — accepted by the bank, awaiting confirmation
- Acknowledged / Paid — the bank has confirmed
- Failed — the bank rejected (it can be retried)
- Cancelled — voided before being sent
Each payment item carries the payee, the payee's bank account, the amount, the currency, and which deal and settlement it traces to.
9.3 What Your CRM Can Do With Payments
The "Do Not Send" toggle is the key feature. An agent team can:
- Place a hold on a single payment for a single client (a settlement is computed and approved, but the cash sits)
- Bulk hold all of a client's outgoing payments
- Release held payments when ready
- Schedule payments for a future date (e.g., consolidate four monthly payments into one quarterly)
- Group by tour, by project, by month for cleaner remittance to the client
All of this is exposed via API. Your CRM can offer the agent a payment dashboard with these controls. The legacy "fold this for me" workflow that ran on email and trust is replaced by a real button.
9.4 Live Visibility
The payment status state machine — Waiting → Pending → Processing → Sent → Paid — is queryable in real time. Your CRM should display payment status on the client and deal pages. An agent who is asked "did my client get paid?" should be able to answer in two clicks.
9.5 Pre-settlement Statements
Before a settlement goes out the door, a pre-settlement statement can be generated (optional). This is the agent or assistant's chance to review the split (commission %, participants, deductions) before money moves. Your CRM can pull these for review and surface them in the agent's queue. A settlement cannot be approved without going through this review where one is required — and the review can be requested via API.
References:
Part 10 — Cross-Subsidiary Payments
A specific case worth its own section because it removes a class of operational pain.
UTA has many subsidiaries, and today, when a check arrives that needs to be split between (for example) UTA and CBG, the workflow is: process half in one office, send a wire to the other office, process the other half there. Currency conversions happen in the middle. Bank fees are paid twice. Settlements are delayed.
In Client Processing, a single cash receipt can be applied across multiple subsidiaries and clients in one operation. The system handles:
- The internal accounting between subsidiaries
- Bank-to-bank transfers (when needed)
- Currency exchange (when needed) at our discretion of timing
- Routing of commissions to the right entity in the right currency
The benefit chain: less manual processing → clients get paid faster → bank fee savings → control of FX timing → less confusion about whose number to use.
For your CRM: this is mostly invisible to the agent. The point to know is that you no longer need to model "which UTA entity is processing this" as a workflow constraint. A single deal can flow through multiple entities; the system sorts it out.
Reference: Settlements Workflow — Cross-Subsidiary Settlement, Bank Ingestion Workflow.
Part 11 — Write-offs and AR Adjustments
Old AR happens. Buyers go bankrupt, deals get cancelled, amounts can never be collected. Today, writing this off is a multi-email exercise between sales ops, the agent, and finance.
In Client Processing, a write-off is a structured workflow with dual approval:
- An agent (or finance) can request a write-off from the AR aging or billing item screen
- The request goes to the agent group for sign-off (agent must approve writing off their own client's AR)
- The request then goes to the finance group for sign-off
- Once both are signed, the write-off posts; appropriate journals are generated; AR shows the item as written off
If the funds are later recovered (the bankrupt buyer's estate pays out, the production company comes back), a recovery posting can be made against the same write-off packet.
For your CRM:
- Surface a "request write-off" action on AR items
- Surface the write-off request queue for agents who need to approve their own
- Show write-off status on AR aging displays
- Show the badge on billing items when a write-off has happened
Reference: Write-Offs Workflow, AR Aging Workflow.
Part 12 — Tax and Withholding
A topic to be aware of even if you do not interact with it heavily.
12.1 The Estimate / Authoritative Pattern
When a billing item is created, Client Processing estimates the tax withholding and VAT components based on the client's tax residency, the contract party, the UTA entity, and the service jurisdiction. These estimates are visible on the billing item display so an agent or finance user can see roughly what the client will net.
When cash actually applies on a worksheet, the tax engine recalculates authoritatively using the actual party setup at apply time. This is what flows into the GL. The estimate may be slightly off; the authoritative number is what counts.
For agent teams, this is important to keep in mind because it drives whether UTA will be withholding tax from the client. There are also times when UTA will include verbiage on the client statement alerting them that they may owe taxes on the money we are sending them (though we are not liable for it).
Part 13 — Responsibility and Task Assignment
Client Processing has a built-in concept of who is responsible for a piece of work, which is useful for routing tasks and for surfacing the right items in the right person's queue. This would be an optional integration but has potential for very clean workflows.
The hierarchy is four levels deep:
- Department (always has an owner)
- Client (may have an owner; otherwise inherits from Department)
- Deal (may have an owner; otherwise inherits from Client)
- Sales Item / Payment Term (may have an owner; otherwise inherits from Deal)
When work needs a person — a write-off needs an agent's approval, an unidentified cash receipt needs an assist, a settlement needs review — the system walks up the hierarchy until it finds a responsible party.
For your CRM:
- You can read the responsible person for any deal, client, or sales item
- You can write/transfer responsibility (with audit trail; the old assignment is deactivated, a new one is created — same immutability pattern)
- You can listen for tasks routed to a user and surface them in your task list
- You can mark tasks complete from your CRM
This is the integration point for "agent inbox" features. An agent should not have to log into Client Processing to see what is waiting on them — your CRM can pull the task list and inline it.
Reference: Assignments Workflow.
Part 14 — Document Management
Documents (contracts, statements, supporting backup) attach at multiple levels:
- Deal level — the executed contract, redlines, side letters
- Sales item level — performance certifications, milestone proof
- Cash receipt level — check images, ACH remittance, deposit slips (PDF slicing is supported when one deposit document covers many receipts)
- Settlement level — back-up documents specific to a settlement
- Write-off packet level — supporting evidence for a write-off
The documents are stored in S3 and have signed-URL access. Your CRM can:
- Upload documents via API
- Retrieve documents via API
- Show inline previews in your UI
- Link a document at one level to another (e.g., a contract uploaded at the deal level can be referenced from a sales item)
Reference: Cash Processing — Document Management, Statements Workflow.
Part 15 — Reporting and Dashboards
Two paths for reporting:
15.1 Canned Reports and Dashboards
Inside Client Processing there are standard reports — AR aging, revenue by department, settlement audit, payment register, agent dashboards, flywheel reports (home department vs. other departments), etc. Many of these can be filtered by your CRM's user perspective via the API. If you want to embed an "AR aging by my agent team" widget in your CRM, the API call exists.
15.2 Reporting APIs and Sigma / Snowflake Sync
Most of the underlying transactional data is available via reporting APIs. The same data is also synced to UTA's analytics warehouse for Sigma and similar tools. If your team has a custom report it wants to build, the data is reachable two ways:
- Real-time, via Client Processing reporting APIs (best for "current state" dashboards)
- Historical / aggregated, via the warehouse (best for trends, year-over-year, forecasting)
For data feeds you build into your CRM, prefer the API path so the freshness is current.
References: Client Processing Scope and Capabilities — Reporting, Technical Architecture.
Part 16 — Notifications and Events
Beyond direct API calls, Client Processing publishes events that your CRM should subscribe to. The key event categories:
- Deal events — created, updated, version superseded
- Sales item events — created, updated, confirmed, status changed
- Payment term events — created, updated, removed
- Billing item events — created (revenue ready), deduction changed, written off
- Cash receipt events — received, tagged, applied, fully applied
- Invoice events — issued, sent, paid, voided
- Settlement events — created, approved, paid out
- Payment events — sent, acknowledged, paid, failed, held
- Write-off events — requested, approved, posted, recovered
- Task events — assigned to user, due soon, completed
- Tax form events — generated, filed
Most of these correspond to a status transition in the Client Processing model, so if you understand the state machines you understand the events. For each one, the event payload includes the relevant references (deal_reference, sales_item_ref, etc.) so you can fetch the current state on the receiving side.
The recommended subscription pattern:
- Subscribe broadly at the system service level
- Filter by department, client, or agent on your side
- Update your CRM display reactively rather than polling
Part 17 — Migration Considerations and Going Forward
A few practical points for IT planning, not a full migration plan.
17.1 The Reference Pattern Is the Key Storage
Whatever your CRM does, store the references. Your existing CRM probably has a "booking number" column or similar. Keep that, and add columns for deal_reference, sales_item_ref, and payment_term_ref. Your search, your filters, and your downstream systems should be able to pivot on these.
17.2 The Clause Library Is a Joint Investment
If your department has unique deal structures that the existing clause library does not represent, that is a conversation to have with the Deal Engine team early. Expanding the clause library is part of every department's onboarding to the new framework.
17.3 Start with Inquiry, Then Add Mutation
A natural staging:
- Phase 1 — Read APIs only. Display deal status, AR aging, payment status, statements in your CRM. Low risk; high agent value immediately.
- Phase 2 — Cash assist. Let agents tag cash receipts.
- Phase 3 — Document workflows. Invoice request, statement request, write-off request via API. Replace the email workflows.
- Phase 4 — Deal authoring. Move deal entry from your legacy path to the Deal Engine.
- Phase 5 — Event automation. Wire your event sources to the event engine.
You do not need to do this all at once.
17.4 The User Experience Doesn't Have to Live in Client Processing
A common assumption: "we will have to send our users to a different app." That is not the model. Client Processing has its own UI for the finance and cash teams that operate it. For agents and assistants, the expectation is that your CRM is the UI. Client Processing exposes the data and the actions; your CRM presents them. The current PoC has agent-facing screens (deal detail, AR aging, statements, tax forms, write-off requests) primarily so we can demonstrate what is possible — but in production the agent can stay in the CRM, and your CRM does the API call.
17.5 Departments That Today Have Their Own Books
Departments that have historically run their own settlement spreadsheets, their own commission calculations, or their own invoicing tooling will see the largest behavioral changes. The Deal Engine plus Client Processing replaces all of that. The shape of your CRM's data model will change less than the shape of your CRM's workflow. Plan accordingly with your finance partners.
Appendix A — Quick Reference: The Three References
| Reference | Lives on | Stable across versions? | Use it to |
|---|---|---|---|
deal_reference | Deal | Yes | Identify a commercial agreement; group sales items |
sales_item_ref | Sales Item | Yes | Identify a unit of work / performance obligation |
payment_term_ref | Payment Term | Yes | Identify a single expected installment |
If you store nothing else from this document, store these.
Appendix B — Related Documentation
| Topic | Link |
|---|---|
| Client Processing high-level overview | overview |
| Client Processing functional approach (immutability, transaction model) | functional-overview |
| Client Processing scope and capabilities (full functional spec) | scope and capabilities v04 |
| Deal Engine overview | Deal Engine overview |
| Deal Engine API specification | Deal Engine Structure and API |
| Deal Engine clause modeling | Deal Modeling, Capabilities |
| Deals workflow (CP side) | Deals |
| Billing items / receivables | Billing Items |
| Cash receipts | Cash Receipts |
| Cash matching | Cash Matching |
| Worksheets (cash application) | Worksheets |
| Settlements | Settlements |
| Payments (outbound) | Payments |
| Bank ingestion | Bank Ingestion |
| Invoicing | Invoicing |
| Statements | Statements |
| Write-offs | Write-Offs |
| AR aging | AR Aging |
| Tax forms | Tax Forms |
| Responsibility assignments and tasks | Assignments |
| Accounting jobs (batch posting) | Accounting Jobs |
| Technical architecture | Technical Architecture |