Payments

Executive Summary

Purpose

This document defines the business requirements, processes, and system functionality for the Payment (Payout) module within the Client Processing application. The module automates and standardizes UTA's client payout procedures while ensuring:

• Accurate distribution of funds after commission deductions
• Proper accounting treatment in subledger and General Ledger
• Complete audit trail for all payout transactions
• Integration with Authoritative Data for party member and bank account information
• Support for both settlement-based and one-off payment scenarios

Scope

This document covers:

• Payment creation from approved settlements (automatic generation)
• Manual payment creation for one-off scenarios (loans, refunds, make-whole payments)
• Payment status lifecycle (Draft → Unposted → Posted)
• Integration with NetSuite GL for automated payment transaction processing
• Integration with Authoritative Data for party member details and bank accounts
• Source UTA account selection for payment execution
• Audit trail maintenance and documentation requirements

Out of Scope

• Inbound cash receipts to UTA from buyers/studios (handled by cash application service)
• Commission calculation and allocation (occurs during billing/cash application)
• Settlement creation, approval workflows, and management (separate FSD)
• Withholding tax calculation (handled at cash application stage)
• Treasury bank account management and reconciliation
• Party member onboarding and bank account setup in Authoritative Data
• Physical check printing and mailing logistics

Objectives

• Ensure accurate and timely payouts to clients and their party members after commission deductions
• Automate payment record creation from approved settlements
• Maintain complete audit trail for all payment decisions and executions
• Integrate seamlessly with NetSuite GL for proper financial reporting
• Support flexible payment scenarios beyond standard deal-based payouts
• Enable client accounting to manage source account selection with appropriate defaults

Business Context

Background

The Payment (Payout) module manages outbound disbursements from UTA to client entities and their associated party members (managers, lawyers, etc.) after agency commissions have been deducted. When a buyer (e.g., studio) pays UTA for client services, the payment is split between UTA's commission (typically 10%) and the client payout portion (typically 90%).

Once both the commission receivable and client payout receivable are fully paid, UTA becomes responsible for distributing the client's 90% share to recipients. This is managed through approved settlements that define payout allocation across multiple party members.

The Payment module supports two scenarios:

1. Settlement-Based Payments: System auto-generates a payment record for each party member upon settlement approval.
2. One-Off Payments: For non-settlement scenarios (loans, refunds, make-whole), users create payment records via the payment screen.

All party member and bank account info is maintained in Authoritative Data (ADA). Payment execution triggers accounting in both the Client Processing subledger (detailed) and NetSuite GL (summarized). Payment status: Draft (incomplete), Unposted (created/pending GL), Posted (GL confirmed).

🚧 TODO: Confirm with Treasury how payment execution will trigger actual check/EFT.

Business Drivers

• Accurate and timely payouts post-commission
• Automation of payment generation from settlements
• Complete audit trail for compliance and controls
• Seamless accounting integration for financial reporting
• Support for diverse, flexible payout scenarios
• Client Accounting can control source account with defaults

Key Stakeholders

• Client Accounting Team: Create and manage payments
• Party Members (Recipients): Clients, loanouts, managers, lawyers, teams
• Treasury/Finance Ops: Execute payments, reconcile accounts
• External Auditors: Review controls, documentation, and accounting

Process Overview

Payment Process Flow

graph TD
  SettlementApproved((Settlement Approved))
  AutoGenPayments((Auto-Generate Payment Records))
  PaymentUnposted((Payment Status: Unposted))
  SendToGL((Send to NetSuite GL))
  GLPosted{GL Posting Success?}
  PaymentPosted((Payment Status: Posted))
  SubledgerUpdate((Update Client Processing Subledger))
  ExecutePayment((Execute Payment to Recipients))

  OneOff((One-Off Payment Need))
  ManualCreate((Manually Create Payment))
  PaymentDraft((Payment Status: Draft))
  CompleteEntry((Complete Entry))

  SettlementApproved --> AutoGenPayments
  AutoGenPayments --> PaymentUnposted

  OneOff --> ManualCreate
  ManualCreate --> PaymentDraft
  PaymentDraft --> CompleteEntry
  CompleteEntry --> PaymentUnposted

  PaymentUnposted --> SendToGL
  SendToGL --> GLPosted

  GLPosted -->|Success| PaymentPosted
  GLPosted -->|Failure| PaymentUnposted

  PaymentPosted --> SubledgerUpdate
  SubledgerUpdate --> ExecutePayment

Figure 1: Payment (Payout) Process Flow – Settlement-Based and One-Off Scenarios

---

Process Description

Settlement-Based Payment Flow

• Automatic Payment Generation: When a settlement is approved, the system consolidates all settlement detail lines for each party member into a single payment record per party member. This ensures that each recipient receives just one payout per settlement, regardless of how many lines exist for them within the settlement details.

  For example, a client may be owed the standard 90% net payout after UTA's 10% commission, but there may also be additional "pass-through" amounts (such as per diem or non-commissionable expenses) allocated to the same client as separate settlement lines. The system aggregates both the net client portion and any additional pass-through amounts, so the issued payment is a single check or transfer covering all lines for that party member.

❓ Design Question:
Can multiple settlements be combined into a single payment (payout) for a party member, or must each settlement generate its own separate payment?
(Clarify this requirement before finalizing the payment aggregation logic.)

The automatic payment record pulls:

• All relevant party member details (from Authoritative Data)
• The total allocated amount (including both standard payout and pass-throughs)
• Identification and flagging of any pass-through components
• Links to the consolidated settlement and billing references

All payments are initially set to Unposted status (i.e., created in the system and sent to NetSuite, but pending GL posting confirmation).

• Source Account Selection: Client Accounting selects the UTA bank account to disburse the payment, with defaults configured per scenario or entity; overrides are permitted for cash management as needed.

• Payment Execution & GL Posting:
  🚧 TODO: Confirm the exact process for triggering check/EFT or other payment execution from the system.
  When ready, payment transaction data is sent to NetSuite for GL posting:

  • Debit: Due to Client
  • Credit: Cash
    Status updates to Posted when confirmation is received from NetSuite.

• Subledger & Audit:

  • Each payment record is logged in the Client Processing subledger, tied back to the originating settlement and all contributing detail lines.
  • Full audit trail retained: parent settlement, associated billing items, GL record links, and user/timestamp for every status change.

One-Off Payment Flow

One-off payments cover loans, refunds, make-whole payments, and other ad hoc disbursements that do not originate from a settlement. These scenarios are initiated and defined in the Client Ledger module (amount, business reason, and party), which acts as the upstream source record for the payment. The detailed behavior, lifecycle, and accounting of Client Ledger entries are specified in a separate Client Ledger FSD; this section focuses only on how those entries drive the Payment module.

• Trigger from Client Ledger

  • A one-off payment is initiated when an approved Client Ledger entry indicates that cash needs to be disbursed (e.g., an approved loan, refund, or make-whole item).
  • The Payment module receives the key attributes from Client Ledger: recipient, amount, scenario type, and (where applicable) the preferred/source UTA account and internal references.

• Manual Payment Creation

  • From the Payment screen, Client Accounting selects the relevant Client Ledger entry and the system pre-populates:
    • Recipient and bank account (from Authoritative Data)
    • Amount
    • Payment Reason / Type (e.g., Loan, Refund, Make-Whole)
  • The user selects or confirms the source UTA account and attaches supporting documentation as required by policy.
  • The payment can be saved as Draft until all information is complete and ready for submission.

• Approval Workflow

  • One-off payment approvals (if required) are driven by configurable rules (e.g., amount thresholds, scenario type, UTA account).
  • Approval changes the payment to ready for execution but does not create any sub-ledger or GL journal entries.
  • Financial impact occurs only when the payment is actually executed (disbursed).

• Execution (Disbursement & Accounting)

  • When the payment is executed:
    • The Payment record is updated to reflect the execution date, method (ACH, wire, check, etc.), and status transitions (e.g., Initiated → In Process → Settled or Failed).
    • At the time of disbursement, the Payment module generates sub-ledger entries and triggers GL posting (e.g., Debit the appropriate asset/expense/liability-clearing account, Credit the selected UTA cash account), using configuration mapped to the Payment Reason / Type.
  • The Payment record maintains a reference back to the originating Client Ledger entry so that downstream reporting and reconciliation can tie the disbursement to its business context.

• Alignment with Settlement-Based Flow

  • Once a one-off payment is submitted, it follows the same status lifecycle and posting mechanics as settlement-based payments:
    • Draft (one-off only) → Unposted → Posted.
  • The main difference is:
    • Upstream source: Settlement vs. Client Ledger.
    • Accounts used in sub-ledger / GL: settlement-related client liabilities vs. loan/refund/make-whole accounts configured for one-offs.

Business Rules

Payment Creation Rules

Settlement-Based Payments:

1. Auto-created upon settlement approval (one per party member)
2. Amounts and allocation inherited from settlement line items
3. Pass-throughs flagged and included in payment record
4. All payees and bank accounts must exist in Authoritative Data

One-Off Payments:

5. Created manually by user for ad-hoc needs (source is CLIENT_LEDGER)
6. Require payment reason and supporting documentation
7. 🚧 TODO: Define approval workflow rules if amount or scenario threshold exceeded

---

Payment Status Rules

Status Lifecycle

1. Statuses: Draft → Unposted → Posted

   • Draft: Used only for one-off payments that are created but not yet submitted.
   • Unposted: Payment has been created and sent for GL posting; awaiting confirmation (all payment types).
   • Posted: NetSuite GL posting has been confirmed and linked to the payment.

2. Irreversibility: Status cannot move backwards once advanced (e.g., Posted cannot revert to Unposted or Draft).

Status Transitions

3. Settlement-based payments: Start directly in Unposted when auto-created from an approved settlement.

4. One-off payments: Move from Draft → Unposted when submitted by Client Accounting (after required fields/docs and any approvals).

5. All payments: Move from Unposted → Posted when a successful GL posting confirmation is received from NetSuite.

---

Source Account Rules

• Default UTA bank per business unit/entity
• Client Accounting can override
• 🚧 TODO: Validate fund availability/account status on selection

---

Payment Execution Rules

• Execution is one-way/irreversible
• 🚧 TODO: Validate funds/account/duplication before execution
• 🚧 TODO: Define programmatic payment trigger for check/EFT

---

NetSuite GL Posting Rules

• Detailed subledger payment records; NetSuite receives summarized by period, dept, account
• GL posting must reference settlement, reason, and link to subledger for audit
• 🚧 TODO: Confirm posting freq (real-time vs. batch)

GL Accounts:

• Debit: Due to Client or liability
• Credit: Cash (UTA account)

---

Audit Trail and Documentation Rules

• All actions (create, status change, GL post) timestamped/user-tracked
• Links to settlement/billing where relevant
• One-off payments attach user documentation
• Payments retain history: create date, status changes, GL confirmation, source account choice
• Documentation/audit logs retained per UTA policy 🚧 TODO: Confirm retention duration

---

Data Retention Rules

• Payments/audit logs kept indefinitely
• Status changes/history records retained
• Posted payments never deleted

---

Security and Access Control Rules

• Only Client Accounting can create one-off payments
• Segregation: creator ≠ approver (if approval needed for one-offs)
• All record access logged for audit
• Only authorized users/processes may change payment statuses

---

Error Handling and Failure Rules

• 🚧 TODO: Define (with Treasury) payment execution error handling.
• GL posting failure: stays Unposted, error triggers Client Accounting notification
• 🚧 TODO: Add retry/manual escalation workflow

Functional Requirements

Automatic Payment Generation (Settlement-Based)

• FR: System auto-creates payment records per party member when settlement is approved
• FR: Records are in Unposted status initially
• FR: Inherit party, percent, amount from settlement
• FR: Mark pass-throughs
• FR: Link payment to settlement for audit

One-Off Payment Creation

• FR: Client Accounting can manually create
• FR: Recipient, reason, and docs required
• FR: Save to draft before full submission
• FR: Submit moves from Draft → Unposted
• FR: 🚧 TODO: Approval workflow rules for one-offs

Source Account Selection

• FR: Default source UTA account by config
• FR: Client Accounting may override per payment
• FR: Drop-down selector for eligible accounts
• FR: 🚧 TODO: Validate fund availability

Payment Status Management

• FR: Status lifecycle and state displayed on payment detail
• FR: No back-steps allowed
• FR: Client Processing and NetSuite strictly updated on status change
• FR: On Unposted, send to GL; on success, update to Posted

NetSuite GL Integration

• FR: System posts payment transactions to NetSuite
• FR: Include settlement reference and reason
• FR: NetSuite responds with Success/Failure and JE ID
• FR: On fail, payment remains Unposted and error displayed; retry/manual escalation process 🚧 TODO

Client Processing Subledger Integration

• FR: All payments logged at detail level
• FR: Maintain links between subledger record and GL journal entry
• FR: Enable drill-downs for audit

Payment Execution

• FR: 🚧 TODO: Define integration/handoff to Treasury for execution of check/EFT

Reporting and Analytics

• FR: Search by multiple fields; export results; run audit history reports

Security and Access Control

• FR: Creation, view, approval, and trace by user role
• FR: Enforce creator ≠ approver discipline

---

User Interface Specifications

Payment Screen

Screen Name: Payment
User Role: Client Accounting (full), Finance VP (view)

Section 1: Payment Search

Purpose: Search/filter payments

Criteria:

• Payment ID
• Recipient Name (autocomplete)
• Settlement ID
• Payment Type (Settlement-Based, One-Off)
• Payment Reason (dropdown)
• Status
• Payment Date Range, Created Date Range
• Amount Range
• Source UTA Account

Actions:

• Search, Clear Filters, Export Results

Results Grid Columns:

• Payment ID, Recipient Name/Type, Payment Type, Reason, Amount, Status, Payment Date, Created By/Date, Settlement ID, Source UTA Account

Grid Actions:

• View Payment Details, Create New One-Off

---

Section 2: Payment Detail View

Purpose: View all payment info and status history

Fields:

• Payment ID, Type, Status, Recipient, Recipient Type, Bank Account (last 4), Amount, Payment Date, Reason/Justification (for one-offs), Settlement ID (linked), Source UTA Account, Created By/Date

Attachments (One-Offs):

• File names, upload date, uploaded by

Status History:

• Status, Date/Time, User, Comments

GL Posting Details (when Posted):

• NetSuite JE ID (link), Date, DR/CR Accounts

Actions:

• Edit (One-Off: Draft only), Submit for Posting (moves to Unposted), Execute Payment 🚧 TODO

---

Section 3: Create One-Off Payment

Purpose: Client Accounting creates/edits a one-off payment

Fields:

• Payment Reason (required)
• Recipient (autocomplete; fills Recipient Type, Bank Acct)
• Amount (required, > $0)
• Payment Date (default: today)
• Source UTA Account (default, editable)
• Justification (required, min. 10 characters)
• Supporting Documentation (file upload; req. before submission)

Actions:

• Save as Draft, Submit for Posting, Cancel

Validations:

• Required fields, recipient must exist + have valid account, must attach docs, amount > 0

Notifications:

• Success/fail for Save or Submit, GL post failure error

Data Model

Payment Entity

Field Name	Data Type	Description
PaymentID (PK)	GUID	Unique identifier for the payment record.
PaymentType	Enum	Indicates whether the payment is Settlement-Based or One-Off.
Status	Enum	Current status of the payment (Draft, Unposted, Posted).
RecipientID (FK)	GUID	Reference to party member in Authoritative Data.
RecipientName	String	Denormalized recipient name for display and reporting.
RecipientType	Enum	Type of recipient (Client, Loanout, Manager, Lawyer, etc.).
BankAccountID (FK)	GUID	Reference to recipient’s bank account in Authoritative Data.
Amount	Decimal	Total payment amount to be disbursed.
PaymentDate	Date	Date the payment is (or is planned to be) executed.
PaymentReason	Enum	For one-offs: Loan, Refund, Make-Whole, Other; optional/unused for settlement-based.
Justification	Text	Free-text explanation for one-off payments; used for audit and approvals.
SettlementID (FK)	GUID	Reference to originating Settlement for settlement-based payments; null for one-offs.
SourceUTAAccountID (FK)	GUID	Reference to the UTA source bank account used for the disbursement.
UpstreamSourceType	Enum	Identifies upstream source module:SettlementorClientLedger.
UpstreamSourceID	GUID	Identifier of the upstream record in the source module (Settlement or Client Ledger).
PassThroughFlag	Boolean	Indicates whether the payment includes pass-through components.
PassThroughAmount	Decimal	Total portion of the payment that is classified as pass-through; null if none.
NetSuiteJournalEntryID	String	Identifier of the corresponding journal entry in NetSuite GL, when posted.
GLPostingDate	DateTime	Timestamp when GL posting was confirmed by NetSuite.
CreatedBy (FK)	GUID	Reference to the user who created the payment.
CreatedDate	DateTime	Timestamp when the payment record was created.
ModifiedBy (FK)	GUID	Reference to the user who last modified the payment.
ModifiedDate	DateTime	Timestamp of the last modification to the payment record.

---

Payment Status History Entity

Field Name	Data Type	Description
PaymentStatusHistoryID (PK)	GUID	Unique identifier for the status history entry.
PaymentID (FK)	GUID	Reference to the Payment record whose status changed.
Status	Enum	Status value at this point in time (Draft, Unposted, Posted).
StatusDate	DateTime	Timestamp when this status became effective.

---

Payment Attachment Entity

Field Name (PK/FK)	Data Type	Description
PaymentAttachmentID (PK)	GUID	Unique identifier for the payment attachment.
PaymentID (FK)	GUID	Reference to the Payment record this attachment belongs to.
FileName	String	Original file name of the uploaded document.
FileType	String	File type/extension (e.g., PDF, DOCX, XLSX).
FileSize	Integer	File size in bytes.
FileURL	String	Storage location or reference for retrieving the file.
UploadedBy (FK)	GUID	Reference to the user who uploaded the attachment.
UploadedDate	DateTime	Timestamp when the file was uploaded.

Open Questions / TODOs

1. Payment Execution Mechanism: How will payment execution trigger check/EFT? Confirm with Treasury.
2. One-Off Payment Approval Workflow: What are the thresholds? Is VP approval needed?
3. Validation Before Execution: Fund checks, account verified, duplicate/prevention rules.
4. GL Posting Retry Logic: Auto retry/manual intervention/escalation logic.
5. GL Posting Frequency: Real-time or batch?
6. Data Retention Policy: Final duration for documentation/audit logs.
7. User Access Roles: Define one-off approval/authority.
8. Payment Failure Handling: End-to-end workflow after execution failures.