Users can now export data in Juniper Square's import format from both completed Capital Events and completed Hypothetical Waterfall events.

This functionality will be available if a given fund family has the investor portal → juniper square setting on (under third-party integration on the fund family profile).

Capital Call & Distribution Exports

From a completed capital event, when juniper square is turned on, users will see the option to Download Juniper Square export .

If the capital event contains both a capital call and a distribution, the users will receive two separate file downloads (as Juniper Square supports separate uploads for Capital Calls and Distributions). If the Capital Event contains an Equalization, the equalization transactions that result in the fund receiving capital will be included in the Capital Call export, and the equalization transactions that result in the fund distributing capital will be included in the Distribution export.

Net Income Export

From a completed hypothetical waterfall event, when juniper square is turned on, users will see the option to Download Juniper Square export .

This will result in one export file that is structured to align with Juniper Square's Net Income import file format.

We’ve introduced an additional Yardi Investment Manager export on subsequent closings, so that users can export Management Fee catch up amounts and equalized offsets to post in Yardi after finalizing a closing.

If Yardi is configured as the Investor Portal (under third-party integration on the fund family profile), any completed closing will display a three dot menu with a download Yardi export option. This will export a file in the Yardi IM ETL import format that includes all management fee catch-up and equalized offset transactions produced from the closing.

In a net capital event, some funds may choose to send out notices to LPs who are receiving money vs. contributing money on different dates, even though the capital activity is thought of as part of the same event (and the cash due to/required from each LP is calculated as a net value). This is commonly done on equalizations, where the equalization distribution may occur 1-2 business days after the equalization contribution.

In March, we've added functionality to support different notice dates for the contribution vs. distribution portion of a net capital event. Upon creating a new draft capital event, users will now see an option to indicate if the Capital event includes contributions and distributions with different dates . When selected, users can provide a different set of dates for the capital call and distribution notices.

The system has an Equalization interest reference date setting that allows users to specify whether equalization interest should be calculated based on the Closing date or the Cash equalization date .

Now that we support the above functionality, and a cash equalization can actually happen on two separate dates (the call or the distribution portions of the equalization), we’ve updated options for the Equalization interest reference date setting to the below:

Some funds treat the transaction date of calls for catch-up management fees from new investors (post subsequent close) as the earliest date fees for that quarter were originally called. In other words, the fund will base the transaction date for the fee call on the date that fees would have been called from the investor had they been in the fund from day one.

Previously, our system always set both the effective date and transaction date of calls for catch-up management fees to the day fees were actually called. We now support configuration to drive this treatment.

Under Fund Family > Profile > Advanced , the user can select how they want to handle the transaction date for calls for management fees:

This setting will impact both the Preferred Return calculation for those calls for management fees, as well as the actual vs. equalized views throughout the product.

This setting will also impact the calls for equalized offsets (e.g. if fees were called for Q1, then there is a subsequent closing in Q2 and the fund calls for fees from new investors, there will be some equalized offsets to call for previously existing investors. When this new setting is on, we will date the transaction for the offset call to be Q1 for all LPs – both new and existing).

We’ve updated the below table that gives insight into how ROC and Preferred Return are calculated in a given cash waterfall run to improve audit-ability of waterfall tiers during a distribution.

Notable updates from the previous version:

We’ve introduced the ability to edit the attributes of the Fund Family’s Credit Facility (such as total commitment, maturity date, etc.) and define an associated effective date of the change, so that the system will maintain a historical view on how these attributes changed over time.

From Credit Facility settings, users can now edit the details on the Credit Facility (previously, this information was entirely read-only).

In the edit modal, the user is required to define an effective date for the change they're making. This date can be in the past, today, or future. If any of the credit facility’s attributes are updated, a new version of the facility is created, either as a current version (if effective date is in the past or today) or scheduled version (if effective date is in the future).

From the Facility Detail’s page, users will be able to see the details of the current credit facility version, as well as table that shows the history of all previous versions. The top Facility Details card will always reflect the latest version of the facility. The badge in that table will communicate if that latest version is current or scheduled (I.e. it’s a created version with an effective date in the future).

Users are now able to configure both a default Rounding methodology, as well as a Credit facility rounding methodology override (optional) in the case where the fund uses a different level of precision when rounding credit facility events.

As part of this work, we’ve introduced a new section on the Profile tab of Fund Family config that breaks out the below settings for Rounding.

Some funds track credit facility investment usage by debt investment usage vs. equity investment usage. If the corresponding debt vs. equity configuration on the credit facility is on, users can now see how their interest expense is allocated to debt vs. equity investment uses in the Detailed Interest Breakdown table.

The new debt and equity sections can be expanded / collapsed. When collapsed, users will see the total interest expense associated debt / equity investment investments (respectively).

Previously, we allowed users to create a principal transaction in the Credit Facility workflow out of order – I.e. a user could create a paydown on 3/1/24, and then backdate a reallocation event as of 2/28/24, and see the tranche values as of 2/28 (however if they tried to complete a reallocation on a tranche that’s already paid down, the system would correctly return an error).

We have updated the validation so users cannot create any Credit Facility Principal Transaction (Drawdown, Paydown, and/or Split & Reallocate Tranches) out of order. If a user attempts to create a draft event with a due date earlier than the latest principal transaction in a completed state’s due date, they will now see the below error message:

We’ve also introduced the below additional points of validation to the interest expense posting flow to improve the user experience:

Some funds exclude GP cash flows in their fund level Gross and/or Net IRR calculation. To solve for this, we’ve introduced two new configs under Fund Family > Profile > Advanced:

When this setting is set to No, the IRR is calculated excluding the GP cash flows and the GP's portion of NAV.

We’ve updated the design of the NAV table to improve user’s ability to understand and validate our NAV calculation.

Summary of changes made:

Previously, we only supported the below three Hypothetical Waterfall Transaction Codes:

We now support the below additional Hypothetical Waterfall Transaction Codes for more granular tracking of P&L components:

Previously, we only supported transferring one commitment per transfer event. Now, users can now transfer multiple commitments from the same investor entity as part of the same transfer event:

In the Transferees & Amounts step, users can still enter multiple transferees, and can enter transfer amounts up until the sum of all selected commitments (I.e. the value shown in before transfer).

The original commitments will be allocated to the recipient investors based on the percentage allocated to the recipient of the sum of all commitments being transferred. For example:

Note that in the above example, the original three commitments transferred to two recipients would result in six new commitments. Recipient commitments would be put in the same investor class as the original commitment. If this needs to be adjusted, users would use the cancel correct workflow.

We've introduced a new report for Hypothetical Waterfall Transactions (in the same format as the Waterfall transactions that references cash waterfall transactions) so users can export hypothetical waterfall transactions at quarter's end as needed.

Previously, in the Investor and Investor Entity Cash Flow views, users could toggle this view between All funds or any single fund. We now support filtering on this view for any combination of fund(s) the investor / investor entity has commitments in:

Error messages are most useful to users when they appear where the error actually happens and when the error happens. With that best practice in mind, we’ve introduced the below error state to specific table cells so we can surface error messages to users where they’ve occurred in a table (vs. in a more general toast message), so the user is more likely to understand and self-correct.

We’ve added a three-dot menu on the Closing History table, which is the same three dot menu available when you click into a closing event. The will allow users to download ETL exports and/or delete draft events without needing to click into the event.

This is a pattern we’ll be introducing to fund family event tables throughout the application over time (e.g. Capital Events, CF Principal Events, CF Interest Expense Events, etc.):