7.24.26 - Intercompany Transaction Bridge Configuration and Transaction Management

Client Request Summary: Kate, a client contact, requested a change in how transaction bridges are processed. Currently, the suggested and balancing lines are grouped together in the target company. The client prefers that these lines remain separated out by individual transactions for better visibility and reconciliation.
Objective: Transition the bridge setup from a "consolidated/grouped" view to an "itemized/individual" view to allow internal teams to reconcile balances by specific GL account, date, security, and description.

Configuration Screen: Within the Fund Accounting module, there is a specific setup row for intercompany bridges (e.g., for the Offshore Feeder $002$ ).
Primary Checkboxes: There are three main checkboxes used during the bridge setup, two of which are critical for this request:
- Group Suggested Lines: By default, this is often checked. It takes individual entries booked to the same GL account at the source level and sums them into a single entry at the target level.
- Group Balancing Lines: This automates the consolidation of balancing entries (the offsets required for double-entry bookkeeping).
Procedure for Modification:
1. Navigate to the relevant setup row (e.g., offshore feeder $002$ ).
2. Uncheck the Group Suggested Lines checkbox.
3. Uncheck the Group Balancing Lines checkbox.
4. Save the changes by clicking "OK" on the setup page.
5. Document the change with a screenshot for internal records.

Suggested Lines Definition: This is a system function that performs the underlying math for a bridge. It references a Mapping Template to identify all source company entries relevant to the bridge and generates the corresponding lines for the target company.
Balancing Lines Definition: In classic accounting, every entry must balance to zero (debits must equal credits). When a bridge is run, the system generates an automated balancing line which is the sum total of all entries created but with the sign reversed.
The "Itemized Receipt" Analogy: Moving from grouped lines to ungrouped lines is compared to an itemized receipt. Instead of seeing one total for all "Groceries," you see each individual item (transaction) listed separately.
Source vs. Target Dynamics:
- Source Company: The entity where original entries are booked.
- Target Company as Investor: The entity that receives the bridged data. The target company is often an investor in the source company, and balances are allocated to the target company based on investor-specific fields (e.g., the investor number field on the fund card).

In a hypothetical scenario, the source company has three entries booked to a random income account ( $400000$ ):

Scenario A: Grouped Settings Checked:
- The system identifies the $400000$ GL account in the mapping template.
- It creates one entry for $600$ at the target level.
- The date of the entry becomes the Posting Date of the bridge document (e.g., $12/31/2025$ ), losing the original entry dates.
- One balancing entry of $-600$ is created (often to account $13800$ or a generic $200$ balancing account).
Scenario B: Grouped Settings Unchecked:
- The system creates three separate entries ( $100$ , $200$ , and $300$ ) mirroring the source.
- The original dates ( $7/12/2025$ , $8/12/2034$ , etc.) are respected and maintained.
- Three corresponding balancing entries are created to represent the breakout correctly.

IRR (Internal Rate of Return): This is a critical business process that requires individual cash flow dates. IRR calculates the percentage return by comparing specific cash flows by date against a total investment balance. Consolidation ruins IRR calculations because it aggregates multiple cash flows into a single date, providing incorrect data.
Audit and Reconciliations: Smaller or more complex fund structures (e.g., Source Fund → Feeder Fund → GP Fund) benefit from the breakout view because it allows users to track entries one-to-one between the source and the target to ensure nothing is missing.
General Preference: Most teams prefer grouped/consolidated views for simplicity, especially for GP funds where the focus is typically on the final unrealized/realized value rather than day-to-day transaction movement. However, the choice is entirely a matter of client preference and their specific niche business processes.

Zendesk Workflows:
- CCed Users: When a user (like Anoop) creates a ticket, they may CC others (like Kate). CCed users can respond, and the system will identify them as the end user for that specific response, even if they didn't initiate the ticket.
- Response Protocol: After updating the intercompany setup, the response should state: "Hi Kate, we have updated the intercompany setup for this fund to break out your suggested and balancing lines. Please let us know if you need anything else."
- Ticket Status: Once the request is fulfilled, the ticket should be submitted as Solved.
Internal Strategy: When setting up new funds (e.g., using the Architect tool), always check existing intercompany setup pages for that client. Follow the established precedent for checkboxes and mapping templates to ensure consistency across the client's funds unless instructed otherwise.

Gus: Asked for clarification on the difference between the grouped and itemized views.
Luke: Explained that checking the box merges entries into one sum to "clear noise," while unchecking provides the breakout. He used the analogy of an itemized receipt to clarify.
Gus: Inquired about how Zendesk handles names of individuals who weren't the original ticket creator.
Luke: Clarified that anyone CCed can respond, and Zendesk will register the specific user who sent each reply.
Luke: Tasked Gus with focusing on the "User Access Queue" specifically, aiming to clear all open and approved tickets (including welcome emails) to ensure a clean queue for the upcoming week. He designated Gus as the "triage king" for Monday and Tuesday.