FunctionalDesign Sample

WFE - Functional Design Document
Version : 4.3
WFE
Functional Design Document
Created by
Palaniappan Rajaram
ThoughtFocus Technologies
Version : 4.3
Current Version 4.3

Date Published 7/10/2014
Approved by
Information Classification Confidential
Document Objective Explain functional design of WFE Waterfall Engine
Related Documents Use case & UI Specification
Change Control
REVISION DATE AUTHOR SECTIONS/PAGES
AFFECTED
REMARKS
3.0 5/2/2014 RP 2.2.3, 2.2.41

Changes in the Entity diagram and merging tier sections
3.1 5/8/2014 GM & RP
 Most of the diagrams are moved to Logical Diagram section.
 4.1: Updated the diagram with Lot
 4.4: Updated the diagram
 Waterfall Estimation: Updated the content based on the working group meeting
discussion.
 Data flow diagrams updated with WFE part highlighted
 Added ULP split allocation for combined waterfall
 Out of Scope section updated with more information
 Issues List: Updated for Waterfall Estimation
 WFE Data Point: Added explanation and diagram
4.0 5/29/2014 RP, GM 1.3, 2.7.2, 2.7.1.1,
2.7.1.2, 2.5.2
 Reference document: Removed version column
 Abbreviations and Acronyms: Sort to display in ascending order
 2.7.2 – Section moved before WFD
 2.7.1.1 diagram updated with Delete WFD, in the case of Rejection
 2.7.1.2 diagram updated with Delete WF result, in the case of Rejection
 2.5.2 – LE Amount and Local amount added
 1.3: New item added for 5 Use cases excel spread sheet link
4.1 6/9/2014 GM, RP 2.3.4, 2.6
Page 2 of 62 14-Sep-23
Version : 4.3
 2.3.4: Fund on-boarding Flowchart added

 2.6: Diagram updated – 2c – Changed the text from AuthX to Authz
 Section: HDS for Static Data
o Removed Commitment Amount and Add-On Commitment Amount as
these have been confirmed to be sent to WFE as transactions.
 Section: WFD Generic Parameters
o Renamed 'Fund Level' or 'Deal Level Waterfall' as 'Total Fund or Realized
Waterfall'
 Section: WFE Data Point
o Added clarity and business rules governing them
 Revised the Sections:
o Payer (ULP) Split Allocations for Combined Waterfall
o Waterfall Stack Manager
o WFE Status & Action
o Waterfall Options
o JE Output Review
o Role Based Security
o Source System Security
o Preferred Return Calculation
o Expense Withholdings
o Output Mapping for Source System
o Reporting
o Projection and Scenario
o Performance Requirement
 Added new sections:
o Drill-down
o Investran under 'Business Process Flow and WFE Workflow'
4.2 6/27/2014 GM, RP 2.5.2, 2.10, 2.11,
2.2.1.12
 2.2.1.12: Investran UDF fields added
 2.5.2: Drilldown: Display BatchId and allow the user to choose the fields to
display
 2.10: Report names are added
 2.11: Project Scenario – Updated to “will be addressed later” from “Out of
Scope”
4.3 7/10/2014 GM, RP 2.2.1.12
 2.2.1.12: Waterfall Group UDF moved under Partner Property
Version : 4.3
Table of Content
1 INTRODUCTION....................................................................................................7
1.1 Purpose...................................................................................................................... 7
1.2 Scope......................................................................................................................... 7
1.3 Reference Documents...............................................................................................7
1.4 Abbreviations and Acronyms...................................................................................7
1.5 Current System Summary........................................................................................8
2 FUNCTIONAL SPECIFICATION...........................................................................9
2.1 Haervest Functionality Summary.............................................................................9
2.2 Source System Data Specification...........................................................................9

2.2.1 Source System Static Data................................................................................................. 9
2.2.1.1 Client............................................................................................................................................. 9
2.2.1.2 Fund Family................................................................................................................................ 10
2.2.1.3 Legal Entity................................................................................................................................. 10
2.2.1.4 Investor (Common Investor).......................................................................................................10
2.2.1.5 Specific Investor.........................................................................................................................10
2.2.1.6 CITCO Common Investor...........................................................................................................10
2.2.1.7 Deal............................................................................................................................................. 10
2.2.1.8 Position....................................................................................................................................... 10
2.2.1.9 Tax Lot........................................................................................................................................ 11
2.2.1.10 Static Data Entity Diagram..........................................................................................................11
2.2.1.11 HDS for Static Data....................................................................................................................11
2.2.1.12 Investran UDF Fields..................................................................................................................12
2.2.2 Source System Transactional Data.................................................................................13
2.2.2.1 Batch........................................................................................................................................... 14
2.2.2.2 Journal Entry...............................................................................................................................14
2.2.2.3 GL Account (General Ledger Account).......................................................................................14
2.2.2.4 Transactions............................................................................................................................... 15
2.2.2.5 Investor Allocation......................................................................................................................16
2.2.2.6 Investran Waterfall Estimation....................................................................................................17
2.2.2.7 Business Events Entity Diagram.................................................................................................17
2.2.2.8 HDS for Transactional Data........................................................................................................17
2.2.3 Upstream System Dataflow Options to Haervest...........................................................18
2.2.3.1 Data from Source System...........................................................................................................18
2.2.3.2 Source System User Access Data..............................................................................................19
2.2.3.3 On-Demand Data – Push request from Haervest Application....................................................19
2.2.3.4 Entity Data Change Management and Versioning......................................................................19
2.3 Waterfall Configuration (Fund Setup)....................................................................20

2.3.1 Event Types....................................................................................................................... 20
2.3.2 Waterfall Types.................................................................................................................. 20
2.3.2.1 Income only Waterfall.................................................................................................................21
2.3.2.2 Income and Sale Waterfall..........................................................................................................21
2.3.2.3 Hypothetical Period Close Waterfall...........................................................................................21
2.3.3 Waterfall Group (WFG)...................................................................................................... 21
2.3.3.1 Typical Waterfall Tiers................................................................................................................22
2.3.3.2 Proceeds Tier............................................................................................................................. 22
2.3.3.3 Return of Capital (ROC) Tier......................................................................................................23
Version : 4.3
2.3.3.4 Management Fee Giveback Tier................................................................................................23

2.3.3.5 Organization Fee Giveback Tier.................................................................................................23
2.3.3.6 Drawdown for Expenses Giveback Tier......................................................................................23
2.3.3.7 Recoup Loss Tier........................................................................................................................23
2.3.3.8 Preferred Return Tier..................................................................................................................24
2.3.3.9 Catch-up Tier..............................................................................................................................24
2.3.3.10 Full Promote Tier........................................................................................................................24
2.3.4 Process to Onboard a Fund in Haervest.........................................................................25
2.3.5 Waterfall Bucket (WFB)..................................................................................................... 26
2.3.6 Event Type & Waterfall Bucket Mapping.........................................................................27
2.3.7 Waterfall Definition (WFD)................................................................................................ 28
2.3.7.1 Waterfall Group and Waterfall Definition Association.................................................................28
2.3.7.2 Waterfall Definition Generic Parameters....................................................................................28
2.3.7.3 Generic Quantity Setup..............................................................................................................29
2.3.7.4 Haervest Data Point (HDP).........................................................................................................29
2.3.7.5 Waterfall Bucket & Transaction Type Mapping...........................................................................30
2.3.7.6 Specific Investor Grouping..........................................................................................................31
2.3.7.7 Waterfall Tier Split......................................................................................................................31
2.3.7.8 Tier Formula Builder...................................................................................................................31
2.3.7.9 Receiver (GP) Split Allocations...................................................................................................32
2.3.7.10 Payer (ULP) Split Allocations for Combined Waterfall................................................................32
2.3.7.11 Waterfall Definition Versioning & Restoring................................................................................32
2.3.7.12 Waterfall Definition Numerical Parameter Versioning.................................................................32
2.3.7.13 Waterfall Definition Approval......................................................................................................33
2.4 Event Review & Waterfall Execution......................................................................33

2.4.1 Waterfall Stack Manager................................................................................................... 33
2.4.1.1 Investran Status..........................................................................................................................34
2.4.1.2 Haervest Status & Action............................................................................................................34
2.4.1.3 Waterfall Options........................................................................................................................35
2.4.1.4 Amount....................................................................................................................................... 35
2.5 Waterfall Output Review & Approval.....................................................................35

2.5.1 Waterfall Output Review................................................................................................... 35
2.5.2 Drill-down........................................................................................................................... 36
2.5.3 JE Output Review.............................................................................................................. 38
2.5.4 Waterfall Approval............................................................................................................. 38
2.6 Role Based Security................................................................................................38

2.6.1 Haervest Functionality...................................................................................................... 39
2.6.2 Harvest Application Permission......................................................................................40
2.6.3 Haervest Functional Role................................................................................................. 40
2.6.4 Source System Security................................................................................................... 42
2.6.4.1 Investran..................................................................................................................................... 42
2.6.4.2 Yardi............................................................................................................................................ 42
2.6.4.3 Aexeo.......................................................................................................................................... 42
2.6.5 Haervest Application Authorization.................................................................................42
2.7 Business Process Flow and Haervest Workflow..................................................43

2.7.1 Investran............................................................................................................................ 43
2.7.1.1 Commitment/Add-on Commitment.............................................................................................43
2.7.2 Yardi................................................................................................................................... 43
2.7.3 Aexeo................................................................................................................................. 43
2.7.4 Future Business Process................................................................................................. 43
2.7.4.1 Future Business Process for Waterfall Definition Setup.............................................................43
2.7.4.2 Future Waterfall Execution Business Process............................................................................44
2.8 Waterfall Calculation...............................................................................................44

2.8.1 Incremental Calculation.................................................................................................... 45
2.8.2 Cumulative Calculation..................................................................................................... 45
Version : 4.3
2.8.3 Preferred Return Calculation............................................................................................ 46

2.8.3.1 Type: Contribution and Distribution Matching.............................................................................47
2.8.3.2 Type: IRR based Preferred Return (Obsolete)...........................................................................47
2.8.3.3 Type: Pref Credit.........................................................................................................................47
2.8.3.4 Interest Compounding Rule........................................................................................................48
2.8.3.5 Day Count Options.....................................................................................................................48
2.8.4 Expense Withholdings...................................................................................................... 48
2.8.5 Giveback Calculations...................................................................................................... 48
2.8.6 Recoup Loss...................................................................................................................... 49
2.8.6.1 Realized Loss.............................................................................................................................49
2.8.6.2 Unrealized Loss..........................................................................................................................49
2.9 Export to Source System........................................................................................49

2.9.1 JE output to Source System.............................................................................................49
2.9.2 Output Mapping for Source System................................................................................50
2.9.3 Data push Options to Investran.......................................................................................50
2.9.3.1 Investran SDK.............................................................................................................................50
2.9.3.2 Investran DIU (Data Import Utility)..............................................................................................50
2.10 Reporting................................................................................................................. 50
2.11 Projection and Scenario (requirements pending – delayed to later iterations). .52
3 USE CASE AND UI SPECIFICATION................................................................53
4 LOGICAL DATA MODEL....................................................................................54
4.1 Static Entities........................................................................................................... 54
4.2 Business & Waterfallable Events...........................................................................55
4.3 Waterfall Group, Waterfall Definition, Waterfall Bucket and Tier Formula..........56
4.4 Waterfall Definition, Waterfall Bucket and Transaction Type..............................56
4.5 Specific Investor & Waterfall Definition.................................................................57
4.6 Client, Fund Family & Source System Database..................................................58
5 NON-FUNCTIONAL REQUIREMENTS..............................................................59
5.1 Performance Requirement (TBD during QA).........................................................59
6 OUT OF SCOPE..................................................................................................60
APPENDIX A. ISSUES LIST....................................................................................61
Version : 4.3
1 INTRODUCTION
WFE is a system intended to implement a Private Equity style Waterfall calculation engine to
support the various funds administered by KKR. The Architecture is aimed at designing this
engine as a service to support the funds housed in Investran, Aexeo and Yardi accounting
platforms.
The core of the system will be a Waterfall Engine that consumes the cash flows from the
accounting system, performs the Waterfall calculation per the rules setup by the user and
produces data to be returned to the accounting system. The system will allow the user to
setup the various formulae involved in the calculation. Further, the system will be
independent of the accounting structure used in the source GL systems.
1.1 Purpose
The purpose of this document is to explain the design of the system to the business
users and to provide a basis for the technical design and development activities. The
document also discusses the interface points between WFE and the other systems
on which it depends ex. Authorization & Authentication providers, data exchange
between the GL systems and WFE e tc.
1.2 Scope
The scope of this document is restricted to the business components involved in and
the behavior of the system. Topics related to the implementation will be covered in
the Technical Architecture and the Technical Design documents.
1.3 Reference Documents

# Document Name Location
1 Waterfall calculation Application http://genportal/sites/aexeoit/FER/Project
- Business Requirement %20Management%20Documents/Private%20Equity
Document (BRD) %20and%20Real%20Estate/Private%20Equity/
Waterfall%20Project/Waterfall%20Requirements/
Waterfall%20Product%20Project%20-
%20Requirements%20Document.pdf
2 KKR – Waterfall calculation http://brn0vmmsapp119:8090/download/
Application - Discovery attachments/15171910/KKR%20Waterfall
Document %20Calculation%20Application%20Discovery.docx?
api=v2
3 Haervest-TechnicalArchitecture http://brn0vmmsapp119:8090/download/
attachments/15171910/Haervest-
TechnicalArchitecture.docx?api=v2
5 5 Use case http://brn0vmmsapp119:8090/download/
attachments/15171914/5UseCases.xlsx?
version=6&modificationDate=1401378046397&api=
v2
1.4 Abbreviations and Acronyms

Acronyms and abbreviations used in this document and the meaning of each:
Version : 4.3
Acronyms Abbreviations
ALP Affiliated Limited Partner
DD Drawdown
DIU Data Import Utility
GL General Ledger
GP General Partner
HAERVEST Hurdle Allocation AExeo Reporting and
diVEstment Scenario modeling Tool
HDP WFE Data Point
HDS WFE Data Specification
IRR Internal Rate of Return
JE Journal Entry
LP Limited Partner
LPA Limited Partner Agreement
MFee Management Fees
OrgFee Organization Fee or Expenses
PE Private Equity
Pref Calc / Pref Return Preferred Return Calculation
RE Real Estate
ROC Return of Capital
SDK Software Development Kit
UI User Interface
ULP Unaffiliated Limited Partner
WFB Waterfall Bucket
WFD Waterfall Definition
WFE Waterfall Engine
WFG Waterfall Group
1.5 Current System Summary

KKR currently uses Aexeo, Axi, Yardi, Excel, MS Access and Investran for managing
Portfolio / Deal / Position / Lot / Partner level cash flow information.
Application Summary
Aexeo Aexeo is the Fund accounting system used for the Hedge funds and
Hybrid funds (Hedge funds with a more Private Equity fund like
structure)
Axi Axi is a sister system to Aexeo which handles the Partner accounting
for the funds in Aexeo. For some of the Hybrid funds, the Partner
accounting is performed in Investran.
Yardi The Real Estate funds are housed in Yardi which provides both Fund
and Partner accounting.
Excel & Transactions of some of the older funds are still maintained in Excel
MS Access and/or MS Access. In some cases, the newer transactions of these
funds are maintained in Investran. If these funds need to use
Haervest, they will have to be migrated to one of the 3 GL systems
identified earlier.
Investran Investran is a General Ledger accounting system which is used to
manage Fund and Partner accounting for the Private Equity funds.
Excel Currently, Excel macro based waterfall model is being used by KKR
Waterfall to perform the Waterfall calculations for the various funds. Data from
Version : 4.3
Model the 3 GL systems are imported into these models before the Waterfall
is executed.
Version : 4.3
2 FUNCTIONAL SPECIFICATION
2.1 WFE Functionality Summary
The WFE system will allow the user to setup a fund i.e. specify the Waterfall
calculation rules to be used for the various investors, run & review the Waterfall
calculations for the realized and unrealized events and provide mapping for data
exchange between the accounting system and Haervest.
User will be able to review the Waterfall calculations on-screen as well as through a
basic set of reports.
In the initial phases, the WFE system is intended to be used by the Fund
Accountants, Controllers and Executives internal to KKR but in the future, the system
may be available for external users such as the Client and the Client’s
representatives. Each user’s level of access to a fund will be controlled through a well
defined authorization model which will be configured by the administrative users at
KKR.
The existing funds will be on boarded in a staggered manner in the following order:
 Phase 1: Investran
 Phase 2: Yardi & Aexeo
WFE application functionality can be categorized as below:

 Reference Data Import from the Source System
 Waterfall rules configuration
 Role Based Security
 Transactional Data Import (Contribution, Distribution & Valuation)
 Waterfall Execution & Review
 Export of processed data to the Source System as Journal Entries
 Report Generation
 Projection and Scenarios
2.2 Source System Data Specification

2.2.1 Source System Static Data
WFE needs certain reference data from the source GL systems. These will be used
for user access, fund setup, calculation and reporting purposes. The reference data
will be required for setting up the fund in WFE much before the transactional data
come into existence.
For each datum, WFE will need an unique ID and a name (and other attributes as
applicable). Since each source GL system may house the clients’ funds on multiple
databases, these IDs may not be unique within a client or across clients. To resolve
this, any data sent from the source systems will need to be accompanied by an
unique ID that represents the source, in addition to the ID of the datum itself.
2.2.1.1 Client
A Client is an entity which has one or more of its funds administered by KKR. For
example, Blackstone is a client which has BREPV & BRESS as funds.
Page 10 of 62 14-Sep-23
Version : 4.3
Investran doesn’t have the Client data point. New UDF field called Client shall be
added under the Legal Entity, which shall have drop down with list of Client with
Client ID. WFE shall receive the Client and Client ID from Investran.
2.2.1.2 Fund Family

One Fund may have more than one Legal Entity, where in each Legal Entity also
called as a Fund in some cases. Group of Legal Entity within a single Fund is called
as Fund Family in Haervest. This way, WFE shall be able to filter out and show the
list of Legal Entities, which all part of one Fund Family.
Investran doesn’t have the Fund Family data point. New UDF field called Fund Family
shall be added under the Legal Entity, which shall have drop down with list of Fund
Family with Fund Family ID. WFE shall receive the Fund Family and Fund Family ID
from Investran.
2.2.1.3 Legal Entity

Legal Entity is part of a singly Fund Family. Each Legal Entity within a Fund Family is
also called as Fund. Group of Specific Investors shall be part of a one Legal Entity.
All the Specific Investors contribution and distribution shall happen through the Legal
Entity.
2.2.1.4 Investor (Common Investor)

An Investor may invest in more than one Fund Family within the Client.
2.2.1.5 Specific Investor

Common Investor’s participation to a single Fund creates a relationship called
Specific Investor. All the contribution and distribution will be booked under the
specific investor within a Fund.
Specific Investors are categorized as below:

Specific Investor Type Description
General Partner (GP) Carry receiving entity
Unaffiliated Partner (ULP) Carry paying entity
Affiliated Partner (ALP)
2.2.1.6 KKR Common Investor

An Investor participating in multiple client funds may ask for a combined report across
client’s Fund. In this case, WFE shall create a KKR Common Investor ID, which shall
link the Client’s Common Investor Id.
2.2.1.7 Deal
Fund makes an Investment into a portfolio company, which is called as Deal.
2.2.1.8 Position
Each slice of an investment within same deal is called as Position/Tranche/Lot.
Investment in a Deal may happen in different times, where in each investment is
called Position.
Page 11 of 62 14-Sep-23
Version : 4.3
2.2.1.9 Tax Lot

Each slice of an investment can be further divided as a Tax Lot.
Any investment tagged with Tax Lot, WFE shall enforce to have the Tax Lot in the
Distribution of the same Investment.
2.2.1.10 Static Data Entity Diagram

Refer the Static Entity Diagram located below at Static Entities
2.2.1.11 HDS for Static Data

Investor related static data:
Field Description
Fund Family ID Group all the LE within a single Fund/Fund
Fund Family Name Family
Fund Family Short Name Optional
Waterfall Group ID Group all the specific investors into a single
Waterfall Group Name waterfall group based on similar waterfall
Waterfall Group Short Name requirement.
Legal Entity ID Specific investor’s contribution and
Legal Entity Name distributions are routed through a Legal
Legal Entity Short Name Entity to a Fund investment.
Common Investor ID Common Investor within a Client may have
Common Investor Name participation in different funds, which shall
Common Investor Short Name create a relation called Specific Investor.
Specific Investor ID
Specific Investor Name
Specific Investor Short Name
Pref Rate Percentage Pref % for the specific investor
GP Catchup Percentage GP catch-up split percentage
GP Total Promote Percentage GP full promote split percentage
Mfee - Investment Period Percentage
Mfee - Post Investment Period Percentage
Deal & Position related static data:

Field Description
Deal ID Deal’s Unique identification number
Deal Name
Deal Short Name optional, in the case of long deal name
Security ID
Security
Security Short Name Optional
CUSIP
Issuer ID
Issuer Name
Issuer Short Name Optional
Page 12 of 62 14-Sep-23
Version : 4.3
Position ID
Position Name
Position Short Name Optional
Lot ID Optional
Lot Name Optional
Lot Short Name Optional
Transaction Type & GL Account related static data:

Field Description
GL Account ID
GL Account Type Name
GL Account Type Short Name Optional
Trans Type ID
Trans Type Name
Trans Type Short Name Optional
2.2.1.12 Investran UDF Fields
UDF Field Name Description

Client Name Unique client name across KKR; to be issued by
the Client Master which is yet to be built by KKR
Client ID Unique client ID across KKR; to be issued from
the Client Master
Fund Family A wrapper to group the various Legal Entities
which make up the fund
PushToHaervest Any Legal Entity with this UDF set to "1" will be
pushed to WFE Staging, along with all the
associated reference and transactional data
Partner Properties:
UDF Field Name Description
Waterfall Group This UDF, associated with a Specific Investor,
categorizes the SIs into groups of investors with
similar Waterfall structure.
Pref Rate Percentage
GP Catchup Percentage
GP Total Promote Percentage
Mfee - Investment Period Percentage
Mfee - Post Investment Period
Percentage
Page 13 of 62 14-Sep-23
Version : 4.3
2.2.2 Source System Transactional Data

WFE shall receive all the source system transactional data by Specific Investor level.
WFE shall not receive the Fund level number from the source system. All the
allocation to the specific investors level are done in the source system only, which
means WFE engine will not do any allocation to specific investor.
In Investran transactions are booked as Batch and one batch per Legal Entity, which
means we cannot have more than one Legal Entity associated with one Batch.
In Investran data is stored in below hierarchy:
Below are the screen shots from Investran, which shows Investran’s Batch:
Page 14 of 62 14-Sep-23
Version : 4.3
-Grid Continuation
2.2.2.1 Batch
Any transaction against a Legal Entity is booked as a Batch in Investran. One Batch
can have multiple Journal entries.
One Batch may have one or more business events. Ex. Investment and Income
2.2.2.2 Journal Entry

Journal Entry is associated to a single Batch and one JE could be tied to a single
business event. Each JE may have two or more Transaction Types (One for Credit
and One for Debit). Within one JE, credit and debit amount has to match.
2.2.2.3 GL Account (General Ledger Account)

Journal Entry can have more than one GL Account. GL Account is mapped to one or
more transaction type.
Below is the GL Accounts list from Investran:
Page 15 of 62 14-Sep-23
Version : 4.3
2.2.2.4 Transactions
Transaction booked against a GL Account. Transaction has Deal, Position, Effective
Date, Credit, and Debit and investor allocation rule. A transaction shall be part of one
JE.
Below is the sample Transaction Type from Investran:
Page 16 of 62 14-Sep-23
Version : 4.3
2.2.2.5 Investor Allocation

Each transaction shall have Investor allocation, which shall have amount allocated to
each specific investor level based on the allocation rule.
Page 17 of 62 14-Sep-23
Version : 4.3
2.2.2.6 Investran Waterfall Estimation

If the Client desires to run a Waterfall calculation with estimated values, to check if
any Carry will be produced, the process required by WFE is for the transactions to be
booked in the source system against a transaction type that is of type ‘Memo’. When
the actual values are available, these transactions should be reversed and the actual
ones booked against a transaction type that is of type ‘Active’.
In Haervest, both the Memo and the Active categories will be mapped to the same
Waterfall Bucket.
2.2.2.7 Business Events Entity Diagram

Please refer Business & Waterfallable Events for the entity diagram discussing the
various source system events.
2.2.2.8 HDS for Transactional Data

Field Description
Page 18 of 62 14-Sep-23
Version : 4.3
Waterfall Group ID
Legal Entity ID
Common Investor ID
Specific Investor ID
Deal ID
Security ID
CUSIP
Issuer ID
Position ID
Lot ID
GL Account ID
BatchId
BatchType
Batch Status
GL Date
Effective Date
Trans Type ID
Trans Type
JE Index
JE Type
Amount
Changed Date Time
2.2.3 Upstream System Dataflow Options to Haervest

WFE application need data from upstream system like Investran / Yardi / Aexeo to
calculate waterfall numbers. Below are the different ways to send the data to
Haervest.
In this phase, only Investran to WFE data flow will be addressed. All other source
system’s data push mechanism will be addressed in Phase-2.
2.2.3.1 Data from Source System

There are three types of data, which WFE need from the source system to execute
the waterfall and generate the waterfall reports.
 User Access
 Static / Reference data
 Transactional data
User Access data addressed in section Source System User Access Data
Static data shall be pushed to WFE database immediately. Source system shall filter
and send only the user, who may need to access WFE application.
Transaction data shall be pushed to WFE database periodically as well as on

demand. This job will run in the source system’s database server. It shall filter and
send only that funds/LE, which is in Haervest.
Page 19 of 62 14-Sep-23
Version : 4.3
Specifically in Investran, transactions are stored with different types of status, which is
Draft, Held or Posted status. WFE shall receive only Held and Posted status
transactions. Other source system
There needs to be a mechanism to send only the new set of records. It should not
send the records, which is already there in Haervest.
Any change in the static data shall be handled separately and pushed to WFE
immediately, where in transactional data changes shall be pushed to WFE as part of
data push Job.
2.2.3.2 Source System User Access Data

WFE will allow the user to access the data based on the user’s permissions in the
respective source system. Each time the user attempts to login into Haervest, these
permissions will be fetched from the source system.
Each source system shall implement a service which allows WFE to query for a
user’s permissions on the source system. If the user is permitted entry into Haervest,
the query result will be persisted in the web session until the user logs out of
Haervest. WFE will not be aware of any changes to the user’s permissions in the
source system until the user logs out of WFE and attempts to login again.
2.2.3.3 On-Demand Data – Push request from WFE Application

Data push job will send the data periodically, which will run based on the predefined
schedule. If user adds any new transaction in Investran, it wouldn’t be available
immediately in Haervest. If user wants the data to be reflected in WFE immediately,
then they need to be able to pull latest data from Investran manually by clicking any
menu or button from Haervest. In this case WFE shall send a data push request to
Investran, which shall trigger the transactional data push.
2.2.3.4 Entity Data Change Management and Versioning

All the entity data changes in the source system need to be reflected in WFE
immediately.
New UDF field called “PushToHarvest” shall be added to Legal Entity. Any static data
associated with the Legal Entity, which has “PushToHaervest” flag enabled shall be
pushed to Haervest.
Note: UDF field concept is related to Investran. Similar settings must be done in other
source system as well.
Below are the different type of changes and action in Haervest:

New Entity Addition:
Any new entity addition in the source system shall be pushed to WFE as long
as it has a link to a LE, which has “PushToHaervest” flag set to True.
Entity Mapping:
Entity mapping information also needs to be pushed from source system to
Haervest. Ex. Common Investor to Specific Investor, Legal Entity to Specific Investor,
Deal to Legal Entity
Page 20 of 62 14-Sep-23
Version : 4.3
Changes:
Every time entity data updated in the source system, WFE will maintain the
version along with the effective date. So this will allow us getting the entity data
based on the effective date any time.
Change in the mapping: Is it possible to change the mapping between entities in the
source system? If it happens in the source system, same needs to be reflected in
WFE along with the Effective Date. This can be done only, if there is no transactional
data associated for the relation. This kind of change needs go through an approval
process.
Deletion:
In WFE data will not be deleted physically, instead it will be flagged as
deleted. Only those entities, which don’t have any transaction associated, can be
deleted. In the case of entity data getting deleted from source system, which has
transaction associated needs to go through an approval process. This will be notified
to the respective Fund Account Manager and the action needs to be taken by them.
Upon their approval entity data and the transaction associated will be deleted.
2.3 Waterfall Configuration (Fund Setup)

2.3.1 Event Types
WFE shall show the data on the stack based on the Event Type. Waterfall Bucket is
associated to an Event Type. Each waterfall bucket consists of one or more source
system’s transaction type.
WFE Stack Manager shall show only those transactions, which is mapped to a
Waterfall Bucket and Event Type.
Below is the list of event type by category:

Event Type Category
Investment Contribution
Management Fees Contribution
Organization Fees Contribution
Drawdown Expenses Contribution
Income Distribution
Sale Distribution
Hypothetical Period Close Unrealized
Loss Loss
ROEC (Return of Excess Capital) Contribution
Partner Transfer Transfer
Sub-Close Equalization Transfer
2.3.2 Waterfall Types

Funds, depending on their LPA, may use one of the following types of Waterfall
calculation.
Page 21 of 62 14-Sep-23
Version : 4.3
2.3.2.1 Income only Waterfall

Income waterfall shall be calculated based on only all the prior Income transactions of
the current deal being distributed and also the prior sale associated to the same deal.
This waterfall shall produce the realized carry.
2.3.2.2 Income and Sale Waterfall

Income and Sale waterfall shall be calculated based on all deals prior realized (sale)
distributions and portion of the Income related to the deal is being distributed. This
waterfall shall produce the realized carry.
2.3.2.3 Hypothetical Period Close Waterfall

Hypothetical waterfall will be used for period close with the Fair Market Value (FMV).
This waterfall shall produce the unrealized carry.
Source system shall provide the valuation for all the deals in the Fund Family for
each Legal Entity. Based on the valuation information, WFE shall calculate the
unrealized carry numbers.
2.3.3 Waterfall Group (WFG)

A Waterfall Group is a collection of Specific Investors with similar Waterfall
calculation requirements and other properties. The Client may wish to see the output
of a Waterfall calculation presented in such groups. The Waterfall Group may
represent just one Legal Entity or may span multiple Legal Entities. This is expected
to be represented in the source system as a name which is associated with each
Specific Investor and conveyed to Haervest. Each Specific Investor shall belong to
one Waterfall Group only.
The Specific Investors in a Waterfall Group for a given Waterfall Type are expected to
have the same Waterfall calculation structure in terms of the number & types of the
tiers.
The following diagram explains the relationship between the Waterfall Group, the
Specific Investor, the Common Investor and the Legal Entity:
Page 22 of 62 14-Sep-23
Version : 4.3
2.3.3.1 Typical Waterfall Tiers

WFE will provide a list of tiers available across the application. These tiers are those
which are typically found in a Waterfall calculation. The WFE user will be able to use
all or a sub-set of these tiers and optionally, adds new tiers.
 Proceeds
 Return of Capital (ROC)
 Management Fee Giveback
 Organization Fee Giveback
 Drawdown for Expenses Giveback
 Recoup Loss
 Preferred Return
 Catch-up
 Full Promote
Waterfall Distribution will be done based on the Waterfall Tier order. Distribution
starts with the first tier and once the tier target is met, then the next tier calculation
starts. Process goes all the way until the distribution amount is distributed 100%.
User shall be able to indicate whether the target paid is a single number or also
tracked at the Deal / Position / Tax Lot level.
2.3.3.2 Proceeds Tier

User shall build this tier’s formula using Waterfall Bucket in Haervest.
Page 23 of 62 14-Sep-23
Version : 4.3
Waterfall calculation starts with Proceeds. User shall not be able to change the order
of Proceeds tier.
Proceeds made up of ROC and Gain portion of a Sale distribution. In the case of
Income, it will be only gain portion.
In the case of Sale of a deal, it includes realized portion of the deal’s income as well
in the case of deal level waterfall. If it’s fund level waterfall, it includes 100% of the
deal income.
2.3.3.3 Return of Capital (ROC) Tier

This tier shall be involved only in the case of Sale event. Portion or the entire capital
being disposed as part of one sale event shall to specific investor as a ROC.
2.3.3.4 Management Fee Giveback Tier

Giveback target percentage shall be calculated based on the capital disposed versus
capital contributed, which shall then be used against the MFee paid by the specific
investor to calculate the target amount.
This amount shall be deducted from the available proceeds from current distribution.
2.3.3.5 Organization Fee Giveback Tier

capital contributed, which shall then be used against the Org Fee paid by the specific
investor to calculate the target amount.
2.3.3.6 Drawdown for Expenses Giveback Tier

capital contributed, which shall then be used against the Drawdown for expenses
paid by the specific investor to calculate the target amount.
2.3.3.7 Recoup Loss Tier

During the fund life cycle, there may be one or more investment, which may not
perform well. Those investments portion or entire investment shall be recorded as
loss, which can be realized or unrealized. User shall be able to enter the loss
Page 24 of 62 14-Sep-23
Version : 4.3
recoupment information for the distribution through Waterfall Options user interface
through event stack manager.
Below is an example of how loss tier target calculated:

Original Loss – Prior Recouped Loss – Reversed Loss (Loss recoupment reversal)
Recoup Loss Options:

 FIFO (Default): First In First Out. Earliest loss shall be recouped first.
 LIFO: Last In Fist Out. Latest loss shall be recouped first.
 Manual: User shall be able to manually enter the loss recoupment amount for
each previous loss.
2.3.3.8 Preferred Return Tier

User shall be able to choose which type of preferred return calculation they want to
apply for the WFD. Preferred return shall be calculated based on the start date and
end date configured in the WFD
Predefined function shall take different set of parameters as explained below:

 Preferred Return Percentage
 Day count Basis
 Compounding
User also shall be able to configure the cash flows, which all will be considered for
the preferred return calculation. Cash flow list shall show below list of items:
 Waterfall Buckets
 WFE Data Points, which get’s generated during the previous tiers in the WFD.
This ways user shall be able to choose the recouped loss from the previous
tier as well.
As of now there are two types of preferred return shall be implemented in WFE as
below:
 Contribution / Distribution matching: Each eligible cash flow shall be
considered to calculate the preferred return.
 Pref Credit: Negative preferred return shall be calculated for the previously
distributed income or sale.
2.3.3.9 Catch-up Tier

Once the preferred return target is met and there is more gain to distribute, then
Catchup target shall be calculated based on the formula specified on the tier. Then
the amount shall be split between payer (LP) and receiver (GP) based on the
percentage specified on the tier.
2.3.3.10 Full Promote Tier

Once the preferred return target and Catchup is met and there is more gain to
distribute, then Full Promote target shall be calculated based on the formula specified
on the tier. Then the amount shall be split between payer (LP) and receiver (GP)
based on the percentage specified on the tier.
Page 25 of 62 14-Sep-23
Version : 4.3
2.3.4 Process to Onboard a Fund in Haervest
Page 26 of 62 14-Sep-23
Version : 4.3
2.3.5 Waterfall Bucket (WFB)

Waterfall Buckets form the internal Chart of Accounts of the WFE system. Since
each fund may use a different set of transaction types in the source system, the
Waterfall Buckets will be used to keep WFE agnostic of the structure used by the
fund.
WFE will allow the user, during fund setup, to map each transaction type to a
Waterfall Bucket. Then, the Waterfall calculation will be represented in terms of
these buckets.
Each Waterfall Bucket will be mapped to an Event Type. The sole purpose of this
mapping is to aid the presenting of the source system’s events on the WFE stack.
The WFE user will be able to add to the list of Waterfall Buckets.
The following tables present the currently known Waterfall Buckets, grouped by their
category.
Capital Contribution related Waterfall Buckets:

Category Waterfall Bucket Name
Investments
Management Fees
Expenses
Organizational Fees
Return of Excess Capital - Overfunding
Distribution related Waterfall Buckets:

Sale - Return of Capital - ROC
Sale - Realized Gain
Sale - Pay down ROC
Sale - Expenses Withheld - MFee
Sale - Expenses Withheld – Org Fee
Sale - Expenses Withheld - DrawdonwForExpenses
Sale - MFee Giveback Paid
Sale – Org Fee Giveback Paid
Sale - Expenses Giveback Paid
Sale - Realized Loss Recouped
Sale - Unrealized Loss Recouped
Sale - Current Promotable Gain
Sale - Pref Return
Sale - Catchup
Sale - Full Promote
Sale - Carried Interest
Income - Gain
Income - Expenses Withheld - MFee
Income - Expenses Withheld – Org Fee
Income - Expenses Withheld - DrawdonwForExpenses
Income - MFee Giveback Paid
Income – Org Fee Giveback Paid
Income - Expenses Giveback Paid
Page 27 of 62 14-Sep-23
Version : 4.3
Income - Loss Recouped

Income - Current Promotable Gain
Income - Pref Return
Income - Catchup
Income - Full Promote
Income - Carried Interest
Loss related Waterfall Buckets:

Realized Loss
Unrealized Loss
Hypothetical (Unrealized) related Waterfall Buckets:

Unrealized Gain / Loss
Unrealized Carried Interest
Unrealized Accrued Expenses
Unrealized Accrued Income
2.3.6 Event Type & Waterfall Bucket Mapping

For each business event, at least one of its Waterfall Buckets will be expected to be
mapped to an Event. Failing this step, the stack will not be able to display the
summary of that event. If multiple Waterfall Buckets are mapped to a given Event
Type, then the values represented by those buckets will be aggregated and displayed
as a single line item.
Ex. If Sale-ROC and Sale-Gain are mapped to the event type ‘Sale’, then the sum will
be displayed on the stack.
Below is an example of Event Type and Waterfall Bucket Mapping:

Event Type Waterfall Bucket
Investment Investment
Management Fees Management Fees
Organization Fees Organization Fees
Drawdown Expenses Drawdown Expenses
Income Income - Gain
Sale - Return of Capital - ROC
Sale
Sale - Realized Gain
Hypothetical Period Close Unrealized Gain / Loss
Loss Realized Loss
Unrealized Loss
Page 28 of 62 14-Sep-23
Version : 4.3
2.3.7 Waterfall Definition (WFD)

Waterfall Definition is a configuration set for one or more specific investors, which
shall be used to calculate the waterfall numbers.
Waterfall calculation has different set of tiers. Each tier calculation shall be defined
based on the LPA for each specific investor. User shall be able to define waterfall
definition for one specific investor or for a group of specific investors.
Waterfall Group can have one or more waterfall definition for a waterfall type.
Because, each specific Investor may have different waterfall definition for the same
waterfall type within the Waterfall Group. User shall be able to define formula for the
tiers defined in the Waterfall Group in the Waterfall Definition. Each tier shall have
formula made up of one or more waterfall bucket.
Waterfall definition includes below configuration, which is required for waterfall

calculation:
 Source system Transaction type mapping to a Waterfall Bucket
 Preferred return calculation date parameters
 Proceeds calculation
 Return of capital calculation
 Giveback calculation for MFee, Org Fee and Drawdown for expenses
 Loss Recoupment
 Preferred Return calculation
 Catchup calculation
 Full Promote
Each specific Investor in a fund must have the Waterfall Definition defined to
calculate Waterfall in Haervest. This shall be done as part of fund setup in Haervest.
2.3.7.1 Waterfall Group and Waterfall Definition Association

A specific Investor can have one Waterfall Definition for each Waterfall Type in a
Waterfall Group.
Please refer Waterfall Definition, Waterfall Bucket and Tier Formula for the logical
model which discusses the Waterfall Group, Waterfall Definition and other related
entities.
2.3.7.2 Waterfall Definition Generic Parameters

Waterfall Definition starts with Generic Parameters, which shall consists of below set
of fields:
Field Description
Combined Waterfall (True or False) Default shall be False. This is required in the
case of combined waterfall in Common
Investor Level.
Total Fund or Realized Waterfall Realized Waterfall: Consider only the realized
Page 29 of 62 14-Sep-23
Version : 4.3
part of the fund along with any prior Income

streams associated with the realized part.
Total Fund: All proceeds and all contributed
capital are considered here.
2.3.7.3 Generic Quantity Setup

User shall be able to define generic quantity or variable, which can be used in any
tier. This quantity can be Static or Runtime. Variable value must be numeric.
Static: User defines the variable and enters the value for the variable or map the
variable value to the partner property, which can come from source system.
Runtime:
 User defines the variable and values shall be entered at the time of running
the waterfall. System will prompt at run time.
2.3.7.4 WFE Data Point (HDP)

In the course of specifying the formula for the calculation of a tier target, the user may
define any number of steps. Each such step will yield a number which is referred to
as the WFE Data Point (HDP). These HDPs range from aggregate numbers to the
most granular numbers which will be required in a report for validation.
Below is the sample diagram, which is based on Management Fee Giveback Target
tier design.
In this diagram, _MFeeGivebackTarget is made up of the following 4 WFE Data

Points:
 _MFeeRemaining,
 _GBFraction,
 _Realization and
 _Contribution.
The HDPs are arrived at by summing up the following Waterfall Buckets:

 “MFee Billed”
 “MFee Given back”
 “ROC”
 “WD”
 “DDE”
 “INV”
 “ADJ” and
 “ROEC”
Note: WFE Data Point names are prefixed with “_”.
Rules governing the WFE Data Points:

1. The Source System shall not push to WFE any WFE Data Points which were
booked into the Source System
2. Any WFE Data Point produced by one Waterfall calculation shall be
consumed, as an HDP, by a subsequent Waterfall calculation. In other words,
the design requires that a WFE Data Point shall be locally consumed instead
of pushing it to the source system and then reading it back into Haervest.
Page 30 of 62 14-Sep-23
Version : 4.3
3. Each Transaction Type in the GL system shall be identified as either ‘Source’

or ‘Haervest’. In other words, a given Transaction Type shall be used to track
either a source produced quantity or a WFE produced quantity but not both.
4. In the existing funds, certain quantities such as MFeeGivenback have been
computed for historical transactions and maintained in an Excel spreadsheet.
When those funds are onboarded to Haervest, a separate Transaction Type
should be used for the historical value and a different one for when that value
is produced by Haervest. If such quantities are required in a calculation, the
user has to provide input to the system as to which HDP to include in any
aggregate function. For example,
a. the MFee given back till date (through historical transactions and
maintained on a spreadsheet) should be mapped to the transaction
type ‘MFeeGivenBack_I’
b. the MFee giveback calculated by WFE should be mapped to the
transaction type ‘MFeeGivenBack_H’
2.3.7.5 Waterfall Bucket & Transaction Type Mapping

Waterfall Bucket shall be mapped to one or more Transaction Types from source
system. Waterfall Bucket mapping can be defined at the WFE application level or
Waterfall Definition level for each source system.
Waterfall Bucket & Transaction Type mapping is explained in the diagram located at
Waterfall Definition, Waterfall Bucket and Transaction Type
Below is the sample Waterfall Bucket to Transaction Type Mapping:

# Waterfall Bucket Transaction Types
1 Investments Cash Received
Investor Cash Call
Cash Call Receivable
Call: Investments
2 Income – Realized Gain Interest Distribution
Page 31 of 62 14-Sep-23
Version : 4.3
Interest Distribution Payable

Distribution Gain to Partners, Stock
Distribution Interest to Partners
2.3.7.6 Specific Investor Grouping

Common Investor may ask for a combined waterfall for all or some of its specific
investors for a specific waterfall type. In this case, partner grouping can be done
within the same waterfall group.
WFD must be created with “Combined Waterfall” flag enabled. If any of the specific
investor having the same WFD within the same common Investor, which has
“Combined Waterfall” flag enabled, shall be combined for waterfall calculation and
report.
Similarly, if any of the specific investor having the same WFD within the same KKR
common investor, which has “Combined Waterfall” flag enabled, shall be combined
for waterfall calculation and report.
2.3.7.7 Waterfall Tier Split

Each tier shall have an option to split the final amount. Split shall be between Paying
entity (LP) and Receiving entity (GP). 100% of the tier result shall split between Payer
and Receiver.
2.3.7.8 Tier Formula Builder

User shall be able to define formula for each tier using the formula builder. Tier
formula can be defined using one or more waterfall bucket or sub formulas, which is
again made of waterfall buckets.
Tier Design Objective:

 Tier shall have split and formulas
Page 32 of 62 14-Sep-23
Version : 4.3
 A tier can be created using Waterfall Buckets. But, there are cases, where in we
need to be able to define part of the formula separately (Quantity or Value) and
then use the Value to build the tier.
 Each tier will have input(s) and output
 User must be able to specify the number of split.
 User must be able to specify percentage formula for each split.
 Split can be categorized into two. 1. Payer 2. Receiver
 Payer is always LP and Receiver could be any GP specific investor entity or
specific investor entity type. Ex. Payer – ULP, Receiver – GP
2.3.7.9 Receiver (GP) Split Allocations

Each tier’s split shall be allocated to Payer (LP) and Receiver (GP). In the end, the
Receiver’s amount, which is aggregated across multiple tiers, needs to be allocated
to actual carry receiving entities.
It could be one or more entity. In the case of more than one entity, amount needs to
be allocated based on some logic. Formula for the logic shall be defined by the user.
System shall list out all the Carry Receiving (GP) entities grouped by LE within the
Waterfall Group. Allow the user to define the formula for each LE’s.
In the case of combined waterfall across multiple LE, system shall allow the user to
define the formula to split the carry between Legal Entities.
2.3.7.10 Payer (ULP) Split Allocations for Combined Waterfall

In a combined waterfall, the cash flows of multiple Specific Investors belonging to a
Common Investor are combined to produce a single number in each Tier. The output
mapping will allow the user to specify the rules using which each number can be split
across the Legal Entities.
2.3.7.11 Waterfall Definition Versioning & Restoring

Waterfall Definition shall be versioned by WFE upon each change. User shall be able
to use the previously saved version. Each time user changes the WFD, WFE shall
save the changes with Effective Date.
Options to apply the WFD changes:

 Applicable from Fund Inception: Apply to all the cash flows from Fund
Inception.
 Applicable from now onwards: Apply only to the cash flows from current
batch/transaction onwards. Earlier cash flows shall use their respective WFD
information based on Effective Date.
2.3.7.12 Waterfall Definition Numerical Parameter Versioning

In general, numerical parameters are defined as part of WFD as one time setup.
Numerical parameters may come from source system or user may enter during the
WFD setup. User may also enter during waterfall execution; in this case numerical
Page 33 of 62 14-Sep-23
Version : 4.3
parameters shall be versioned along with effective date. User may choose to apply
the new parameter as below:
 Applicable from Fund Inception: Apply to all the cash flows from Fund
Inception.
 Applicable from now onwards: Apply only to the cash flows from current
batch/transaction onwards. Earlier cash flows shall use their respective WFD
information based on Effective Date.
2.3.7.13 Waterfall Definition Approval

Waterfall Definition shall be setup by Fund Accountant. Once it’s setup in Haervest,
KKR and Client Fund Account Manager shall be able to review and approve the
WFD. User also shall be able to provide comments during approval or rejection.
Approved WFD shall be versioned. Any change after that need to go through the
approval process. At a given point of time only one approved WDF allowed for a
specific investor and for a waterfall type.
2.4 Event Review & Waterfall Execution

Data on the Waterfall Review screen displayed based on the Client and Fund Family.
Transactional data are pushed from the source system to WFE based on the WFE
Data Specification. User shall be able to review the list of transaction and process the
waterfall for any event on the UI.
2.4.1 Waterfall Stack Manager

The WFE Stack is the dashboard through which the user will be able to verify the
business events from Investran and act upon the Waterfallable events to perform the
Carry calculation. The data from Investran arrive in batches. A single batch may
contain one or more events i.e. contribution, distribution etc. The stack will present
each event as a single line item at the deal level, where applicable.
To present the contents by event type, the stack will use the ‘Waterfall Bucket to
Event Type’ mapping provided by the user for each fund family. Based on this
mapping, the Specific Investor level amounts will be aggregated and shown at the
Legal Entity level. If more than one Waterfall Bucket is mapped to an Event Type, all
amounts contained in those buckets will be aggregated.
The stack will show each line item color coded based on the status of the event. A
color legend will be shown at the top of the stack.
# Field Name Description

1 Batch ID
2 Event Type Event type associated to the Waterfall Bucket
3 Investran Status
4 Legal Entity
5 Effective Date
6 Deal
7 Position
8 Tax Lot
Page 34 of 62 14-Sep-23
Version : 4.3
9 Changed Date
10 GL Date
11 Changed By
12 WFE Status & Action Status data shall be displayed along with the action button
right next to it.
WFE Status: Unprocessed, In-Progress, Processed, Error,
Posted, Approved.
Action: Process, Cancel, Review & Approve
13 Amount
14 Waterfall Options
A sample layout of the Waterfall Stack Manager user interface has been presented
below:
2.4.1.1 Investran Status

Only below status from Investran shall be shown under this column:
 Held
 Posted
 Deleted: Any batch, which was pushed to WFE and deleted later in the
source system, would keep it in WFE with the status as “Deleted”. This
data wouldn’t be considered for the waterfall calculation.
2.4.1.2 WFE Status & Action

WFE Status:
 Unprocessed: Waterfall not processed in Haervest.
 Processed: Waterfall processed in Haervestand the results ready for review
by the user.
 Approved: Results reviewed and approved by the Fund Account Manager.
 Posted to Investran: Results posted to Investran.
WFE Action:
The following actions will be available to the user:
 Process / Re-Process: Process the Income / Sale / Hypothetical waterfall.
Page 35 of 62 14-Sep-23
Version : 4.3
 Approve: Approve the results.

 Post to Investran: Post the waterfall results back to Investran.
2.4.1.3 Waterfall Options

The ‘Waterfall Options’ user interface provides the user with the ability to tweak the
Waterfall calculation by overriding the default actions. From the stack, the user will
be able to specify the overrides for a single event or multiple events.
Loss Recoupment:
LIFO / FIFO / HIFO / Manual
If the ‘Manual’ option is chosen, the user will be presented with the
outstanding losses in the Legal Entity. The Loss Tier formula will be used to
aggregate the loss amounts of all of the Specific Investors in the Legal Entity. The
following information will be present:
 Deal
 Position
 Tax Lot
 Original Loss
 Prior Loss Recouped
 Loss Reversal
 Remaining Loss
 Target Loss Recoupment
Carry Throttling:
Using this option, the user will be able to limit the amount of Carry that the Waterfall
will produce for the given event.
Date override:
Records with ‘Effective Date’ less than or equal to ‘Measurement Date’ will be
selected for the Waterfall calculation. This default can be overridden to use GL Date
instead. In rare cases, the user may want to limit the records using both the Effective
Date and the GL Date.
2.4.1.4 Amount
Aggregated dollar amount from all the specific investor within the same batch and
transaction type shall be displayed under this column. Data shall be aggregated
based on the Event Type as well.
2.5 Waterfall Output Review & Approval

2.5.1 Waterfall Output Review
Once user executed waterfall through the stack manager, user can review the
waterfall output and provide any comments.
Waterfall output screen shall be shown based on source system BatchId. UI shall
provide all the specific investors grouped by Waterfall Group and Carry paying and
receiving investors.
Page 36 of 62 14-Sep-23
Version : 4.3
Output screen data displayed based on the tiers defined in the waterfall definition.
Each tier’s target and actual (paid) will be displayed on the UI. Some of the tier may
not have actual.
Below are the lists of possible generic tier and target, which shall be displayed on the
waterfall output review screen:
Output Data Field Description

Investor Name of the specific investor
Proceeds Gain portion of a Sale or Income or Hypothetical event
Return of Capital Realized capital of a Sale event
MFee Giveback Target MFee giveback target calculated based on realization
MFee Giveback Paid MFee giveback paid based on available proceeds
OrgFee Giveback Target OrgFee giveback target calculated based on realization
OrgFee Giveback Paid OrgFee giveback paid based on available proceeds
Drawdown Expenses Drawdown Expenses giveback target calculated based
Giveback Target on realization
Drawdown Expenses Drawdown Expenses giveback paid based on available
Giveback Paid proceeds
Loss Recoupment Target Available loss as of current distribution
Loss Recoupment Paid Loss recouped based on available proceeds
Preferred Return Target Preferred return target amount calculated based on
WFD
Preferred Return Paid Preferred return paid based on available proceeds
Catchup Target Catchup target calculated based on WFD
Catchup GP Split Catchup GP split paid based on split %
Catchup LP Split Catchup LP split paid based on split %
Full Promote Target Full promote target calculated based on WFD. It is just
remaining proceeds after catch-up tier.
Full Promote GP Split Full Promote GP split paid based on split %
Full Promote LP Split Full Promote GP split paid based on split %
Net LP Distribution Aggregate all the LP distribution
Net GP Distribution Aggregate all the GP carry distribution
2.5.2 Drill-down
This will be a key feature of WFE to allow the user to see the details of the calculation
behind every number that is shown on the Waterfall output screen.
When a number is clicked upon, the formula and the other numbers which were used
to compute that number will be displayed on a pop-up window. Subsequent clicks
will reuse the same window to show the next level of detail. Further, the window will
have a ‘Back’ feature which allows the user to move to the previous level.
As part of the Tier calculation, each WFE Data Point will be stored with the numbers
and the formula which gave rise to the HDP. These will be stored in a tree structure
in the WFE Database. The root of the tree will be the number that is shown on the
Waterfall output screen. As each node of the tree is clicked upon, the next level in
the sub-tree will be fetched for display.
Page 37 of 62 14-Sep-23
Version : 4.3
The attributes shown as part of the drill-down will vary based on the data point whose
details are being shown. Where applicable, the Batch ID will be shown along with the
detail. Ability to allow the user to choose the fields to be displayed on the drilldown
reports will be considered when development occurs.
Example #1:
Final report #: Mfee Target
Click # Title: Mfee Target
1 Final report # = _MFeeRem x _GBF

2 _MFeeRem = MFeeBilled - MFeeGivenBack
3 MFeeBilled = TT Date Amount
4 MFeeGivenBack = TT Date Amount
Example #2:
Final report # Proceeds
Click # Title: Proceeds
1 Proceeds = SP + IP
2 SP = Event Deal Date Amount

A
B
C
3 IP = Event Deal Date Amount

A
B
C
2.5.3 JE Output Review

In order for the Waterfall results to be booked into the source system, the results
have to be presented in the form of Journal entries and packaged into a batch. The
Page 38 of 62 14-Sep-23
Version : 4.3
Journal entries will be created based on the ‘WFE Data Point to Trans Type’ mapping
specified in the ‘Output Mapping’ section of the WFD. Any batch produced by WFE
will bear the batch type ‘Haervest’.
In the review UI, the user will be able to view and verify the contents of the batch.
The screen will show the JE output by grouping the specific investors in a Legal
Entity.
Following is a list of columns which will be shown on the JE output review screen:
JE Output Data Field Note

Investor Name of the specific investor
GL Date Default will be Measurement date. But, user can provide
different date.
Batch Type ’Haervest’
Batch Description User can provide the description
GL Account Populated as defined in the WFD
Transaction Type Populated as defined in the WFD
Deal Populated from Waterfallable event. i.e., Income / Sale /
Hypo
Position Populated from Waterfallable event. i.e., Income / Sale /
Hypo
Lot Populated from Waterfallable event. i.e., Income / Sale /
Hypo
Effective Date Default will be Measurement date. But, user can provide
different date.
LE Amount The WFE Data Point that is to be booked in the source
system.
Local Amount The same WFE Data Point repeated here.
If there are other required fields for posting a batch in the source system, WFE will
provide default values for those fields.
2.5.4 Waterfall Approval

Fund Account Manager or authorized user can approve the waterfall upon reviewing
the waterfall results.
User can either approve or reject the waterfall results along with comments for each
action. In the case of “Approval”, transaction can be posted to the source system. In
the case of “Reject”, user can reprocess the waterfallable event.
2.6 Role Based Security

User access to WFE functionality will be based on a two-step process. First, each
user will be setup with a role that reflects their business function ex. Fund Controller,
Fund Accountant etc. Each of these roles will be setup to access these
functionalities according to the permissions assigned for that role. This setup will be
housed in the security stack provided by Aexeo IT. Second, the data entitlement
pertaining to the user in each source system will be used to determine if that user
should have access, in Haervest, to a particular fund family which belongs to a client.
Page 39 of 62 14-Sep-23
Version : 4.3
Per agreement with the business users, the source system will be queried for the
data entitlement, at the start of an user session in Haervest. Once the user session
begins, WFE will not be aware of any changes to the user’s data entitlement in the
source system until the next time that user attempts to login into Haervest.
The following steps in the specified order must be satisfied in order for an user to be
able to successfully access a fund in Haervest:
 User must be successfully authenticated at the KKR portal and setup to access
Haervest. An user not setup to access WFE will not see the WFE icon.
 Sufficient role assigned to the user in the Aexeo AuthZ application. Each role
should have the appropriate permissions assigned to access the various
functionalities.
 In the source systems (Investran/Yardi/Aexeo), the user must have the
permissions equivalent to one of the following: a read-only user, a Fund
Accountant or a Controller.
The following diagram describes the steps for setting up an user to access a fund that
is housed in Investran:
2.6.1 WFE Functionality

Following is a list of WFE functionalities which may be modified during the lifecycle of
the system.
Functionality Description
Fund Setup Add/Edit a fund information, transaction mapping and waterfall
definition setup.
Reports Access the reports, if any.
Waterfall Execution Execute the waterfall calculation and post results back to the
source system.
Page 40 of 62 14-Sep-23
Version : 4.3
Scenarios Add new scenario, post transactions in scenario and execute

waterfall.
WFE Administration Setup application level Event Types, Tiers, Waterfall Buckets etc
2.6.2 Harvest Application Permission

For each role, the following list of permissions may be applied to the functionalities
listed in the previous section.
Permission Description
Read Only Read only access to any assigned Application Functionality.
Read Write Read and Write access to any assigned Application
Functionality.
Execute Execute access to assigned Application Functionality.
Approve Approve access to assigned Application Functionality.
Post Post access to assigned Application Functionality.
2.6.3 WFE Functional Role

Each WFE user may be assigned one role from the following list:
Role Description
FA shall be able to setup the fund, execute waterfall, post
Fund Accountant (FA) results to Investran, setup scenarios and run reports.
Fund Account Manager FAM shall be able to review the fund setup, review waterfall
(FAM) results and approve and run reports.
Reporter Able to run report and export report
Executive shall be able to see the overview of the fund
Executive performance and run reports.
WFE Admin User can add / edit Event Type, Tier, Waterfall Bucket
Each Role shall have specific set of Application Functionality and Permission defined
as below and each role’s Application Function and Permission can be different based
on the Client.
Role Permission Setup
Functionality \ Read Read Execut Approve Post

Permission Only Write e
Fund Setup X X
Reports X
Fund Accountant (FA)
Waterfall Execution X X
Scenarios X
WFE Administration
Fund Account
Manager (FAM) Functionality \ Read Read Execut Approve Post
Page 41 of 62 14-Sep-23
Version : 4.3
Fund Setup X X
Reports X
Waterfall Execution X X
Scenarios X
WFE Administration

Fund Setup
Reports X
Reporter Waterfall Execution
Scenarios
WFE Administration

Fund Setup
Reports X
Executive
Waterfall Execution X
Scenarios
WFE Administration

Fund Setup
Reports
WFE Admin
Waterfall Execution
Scenarios
WFE Administration X
2.6.4 Source System Security

The source GL systems will provide the data entitlement for the users which will be
used in conjunction with the authorization setup for those users in AuthZ. Each WFE
user should have some level of access to the source system’s database. This is
essential for that user to be able to see the data in Haervest.
Page 42 of 62 14-Sep-23
Version : 4.3
2.6.4.1 Investran
The clients may be housed in Investran on a multi-tenant basis. On request, some
client may have their own Investran database. In some cases, this may lead to a
single client spanning multiple databases for their fund families. However, each fund
family will be housed in a single database only i.e. fund families shall not span
databases.
Investran provides the following two levels of security to access data:

 Database level security through the SQL Server
 Application level security through Team security (CRM)
Each user needs to be added in the SQL Server database using their AD account.
Then the user is given permission to access a specific client’s funds through
Investran CRM.
The Investran development team will make available a federated service which will
be accessed by WFE to check a particular user’s data entitlement in the source
system.
Please refer Client, Fund Family & Source System Database for the diagram.
2.6.4.2 Yardi
Q: What kind of security in place in Yardi?
<TODO>: Phase II
2.6.4.3 Aexeo
<TODO>: Phase II
Q: What kind of security in place in Aexeo?
2.6.5 WFE Application Authorization

User must be authorized to access any of the client’s funds in Haervest. User’s
authorization shall be based on user’s source system authorization and Aexeo Authz
authorization.
User’s authorization shall be in Client level and Fund Family level. If the user
authorized to a Client, user also authorized to access the entire fund’s within the
client by default. Or else, if user is given authorization to a specific fund within the
client, user wouldn’t be able to access other fund within the client.
Ex:
User Client Fund Family
User A Client 1 All
User B Client 1 Fund Family A
User B Client 1 Fund Family B
In the above scenario, User A has access to all the fund families within Client 1. But,
User B has access to only Fund Family A and Fund Family B within Client 1.
Page 43 of 62 14-Sep-23
Version : 4.3
2.7 Business Process Flow and WFE Workflow

The business events and the waterfall events are booked in the source system either
per request from the client or by the clients themselves. These events have to be
processed through WFE for the Carry calculation.
This section discusses the details of how each event is booked in the source system.
2.7.1 Investran
2.7.1.1 Commitment/Add-on Commitment

An Investor’s commitment or changes to the commitment are handled as transactions
in Investran. These activities are mapped to separate transaction types and will be
sent to WFE as part of the transactional data feed. These events will be used in
‘What-If’ analyses.
2.7.2 Yardi
<Phase II>
2.7.3 Aexeo
<Phase II>
2.7.4 Future Business Process

2.7.4.1 Future Business Process for Waterfall Definition Setup
The following data flow diagram explains the future business process to setup a
Waterfall rule in the WFE system:
Page 44 of 62 14-Sep-23
Version : 4.3
2.7.4.2 Future Waterfall Execution Business Process

Below data flow diagram explains the future waterfall execution business process:
2.8 Waterfall Calculation

Waterfall calculations are triggered when one of the following events occur in the
fund: Sale, Income, Clawback and Period Close Valuations.
These events are chiefly handled in one of 2 ways (though there could be other
variations):
 Realized Waterfall (American style): Carry is calculated on the realized
portion of the fund. In this method, there is potential for a Clawback situation
in the latter part of the fund’s lifecycle if the remaining deals do not perform
well.
 Total Fund Waterfall (European style): Here, Carry is calculated only after
the LP has received all or a portion of the contributions made plus the
preferred return on the contributions. In this method, the GP is not likely to
receive any Carry for a substantial period.
Page 45 of 62 14-Sep-23
Version : 4.3
Sale, Income and Interim Clawback result in cash Carry. The Period Close
Valuations result in unrealized Carry or Clawback.
The Waterfall calculation filters the Proceeds of the event through a number of steps
(tiers) before Carry is produced for the GP.
2.8.1 Incremental Calculation

Each distribution shall be treated separately within the Fund Family and Legal Entity.
In the incremental calculation, it always negates the previously distributed amount
and uses the currently being distributed amount only for the waterfall calculation.
Ex:
BatchId Event Deal GL Date ROC Gain

1004 Sale IBM 5/1/2014 $ 30,000.00 $ 15,000.00
1003 Sale Microsoft 3/1/2014 $ 75,000.00 $ 10,000.00
1002 Sale IBM 12/1/2013 $ 20,000.00 $ 5,000.00
1001 Investment Microsoft 3/1/2013 $ 200,000.00
1000 Investment IBM 1/1/2013 $ 100,000.00
In this example at the time of BatchId 1004 distribution, system shall consider:
ROC = $ 30,000.00 for ROC
Gain = $ 15,000.00 for Gain
Total Proceeds = $ 45,000.00
Any giveback or loss recoupment done based on the current distribution only.
2.8.2 Cumulative Calculation

In the Cumulative calculation, each prior distribution amount shall be considered for
the calculation.
BatchId Event Deal GL Date ROC Gain

1004 Sale IBM 5/1/2014 $ 30,000.00 $ 15,000.00
1003 Sale Microsoft 3/1/2014 $ 75,000.00 $ 10,000.00
1002 Sale IBM 12/1/2013 $ 20,000.00 $ 5,000.00
1001 Investment Microsoft 3/1/2013 $ 200,000.00
1000 Investment IBM 1/1/2013 $ 100,000.00
In this example at the time of BatchId 1004 distribution, system shall consider:
ROC = $ 125,000.00
Gain = $ 30,000.00
Total Proceeds = $ 155,000.00
Any giveback or loss recoupment done based on all the distribution.
Reference spread sheet provided below has the cumulative waterfall calculation:
Cumulative Waterfall Calculation
Page 46 of 62 14-Sep-23
Version : 4.3
2.8.3 Preferred Return Calculation

The purpose of the preferred return is to guarantee investors a minimum return on
their invested capital before profits are shared with the GP. In that manner, the
preferred return is merely a priority of return, and is subject to a catch-up by the
sponsor if aggregate fund profits on capital contributions exceed the hurdle.
Preferred return percentage is usually from 7% to 12%. But, this shall be decided by
the GP, which is mentioned in the LPA.
Preferred return is calculated using the Pref Start and Pref Stop dates. These dates
provide the start and stop points for the interest calculation. Depending on the LPA,
the Pref Start date may be one of the following:
 Investment Date
 Partner Contribution Date
 Partner Contribution Date + ‘n’ days – This occurs only when the contribution
is made before the Investment occurs and the Investment doesn’t occur for ‘n’
days after that contribution.
Similarly, the Pref Stop date may be one of the following:

 Date of Income or Sale i.e. Fund activity date
 Distribution Date – date when the proceeds are actually distributed to the
Investor
 Note: In the latter, the Distribution Date is a planned one. If the distribution
doesn’t actually occur on that date, then the Investor will be owed additional
interest from the planned Distribution Date till the actual one. This correction
is taken into account during the next distribution.
Preferred return is provided on all contributions for Investments. Depending on the

LPA, the Investor may also be eligible to receive a preferred return on fees and
expenses.
The various ways of calculating the Preferred Return have been explained in the
subsequent sections, using the following sample set of events:
Event
ID Event Deal Amount Date
1 Inv A $250,000.00 1/15/2007
2 Inv B $175,000.00 5/10/2007
3 Sale A $100,000.00 6/23/2008
4 Inv C $125,000.00 8/12/2008
5 Sale A $50,000.00 4/23/2009
6 Sale B $75,000.00 6/25/2009
7 Sale C $25,000.00 7/3/2009
2.8.3.1 Type: Contribution and Distribution Matching

In this method, each Contribution event is matched with a Distribution event which
relieved all or a part of that Contribution. The Contribution event provides the
Preferred Return Start date and the Distribution event the Preferred Return Stop
Page 47 of 62 14-Sep-23
Version : 4.3
date. The capital distributed through the distribution event is the principal on which
the interest is calculated.
Contribution/Distribution Matching
Calc Date 11/20/2009 Comp. Interest P(1+R)^n
Event
ID Event Deal Amount Interest Start Interest End Interest Amount
3 Sale A $100,000.00 1/15/2007 6/23/2008 fnCompInt()
5 Sale A $50,000.00 1/15/2007 4/23/2009 fnCompInt()
6 Sale B $75,000.00 5/10/2007 6/25/2009 fnCompInt()
7 Sale C $25,000.00 8/12/2008 7/3/2009 fnCompInt()
2.8.3.2 Type: IRR based Preferred Return (Obsolete)

Per email from Tamir on 3/21/2014, the IRR based pref calculation is no longer
required to be implemented in Haervest.
2.8.3.3 Type: Pref Credit

In this method, each event, contribution and distribution, is used separately for
interest computation. The principal involved in each event increases or decreases
the interest expectation. Positive interest is calculated for each contribution event,
from the Pref Start date to the current Pref Stop date (i.e. Measurement date).
Negative interest is calculated for each distribution event on the return of capital from
the event’s actual distribution date (i.e. the date on which the proceeds are sent to
the Investor) to the current Pref stop date (i.e. Measurement date). The net amount
is the Preferred Return amount for the Investor.
Preferred Return Credit

Calc Date 11/20/2009 Comp. Interst P(1+R)^n
Event
ID Event Deal Amount Interest Start Interest End Interest Amount
1 Inv A $250,000.00 1/15/2007 11/20/2009 fnCompInt()
2 Inv B $175,000.00 5/10/2007 11/20/2009 fnCompInt()
3 Sale A ($100,000.00) 6/23/2008 11/20/2009 neg. fnCompInt()
4 Inv C $125,000.00 8/12/2008 11/20/2009 fnCompInt()
5 Sale A ($50,000.00) 4/23/2009 11/20/2009 neg. fnCompInt()
6 Sale B ($75,000.00) 6/25/2009 11/20/2009 neg. fnCompInt()
7 Sale C ($25,000.00) 7/3/2009 11/20/2009 neg. fnCompInt()
Reference spread sheet provided below has the pref credit preferred return
calculation, which is highlighted in red color on the spread sheet:
PrefCredit Preferred Return Calculation
Page 48 of 62 14-Sep-23
Version : 4.3
2.8.3.4 Interest Compounding Rule

Depending on the LPA, the user will be able to select one of the following interest
compounding rules for the interest calculation:
 Annual
 Anniversary
 Quarterly
 Monthly
 Weekly
 Daily
 Continuous
 Simple i.e. no compounding
If the interest computation were to terminate between 2 compounding dates, the

principal may accrue a simple interest for the days in the current compounding
period. This will be configurable, allowing the user to specify the type of
compounding to be applied in such cases.
2.8.3.5 Day Count Options

Using this, the user will be able to specify the number of days in the interest accrual
period and the number of days in the reference period. The list of commonly used
options is as follows:
 Actual / Actual
 Actual / 365
 Actual / 360
 30 / 360
In each, the numerator specifies the number of days in a month and the denominator,
the number of days in a year.
2.8.4 Expense Withholdings

If the expenses are not drawn through a separate capital call, the fund may choose to
withhold the expenses from the proceeds or the gross gain of the Distribution event.
This results in the reduction of the net gain that is subject to Carry computation.
2.8.5 Giveback Calculations

Specific Investor pays the Management Fee, Organization Fee and other expenses
during the fund life cycle. Whenever fund does the sale distribution, specific investors
are expected to receive the portion of the Fees given back to them as credit before
GP takes the carry.
Giveback target is calculated based on below calculation:
Numerator: Numerator consists of the realized portion of the Fund, which is ROC,
Writedown, and Drawdown Expenses.
Denominator: Denominator consists of the contribution portion of the Fund, which is

Investment, Adjustment, Drawdown Expenses and Return of Excess Capital.
Page 49 of 62 14-Sep-23
Version : 4.3
Giveback Fraction = (ROC + Writedown + Drawdown Expenses) / (Investments +

Adjustments + Drawdown Expenses – ROEC)
Fee Giveback Remaining = Fee Billed – Fee Given back
Giveback Target = Fee Giveback Remaining * Giveback Fraction
2.8.6 Recoup Loss

During the waterfall distribution, Fund shall valuate other deal’s performance. If any of
the deal is not performing well and which could potentially lead to loss. This kind of
underperforming deals capital can be recouped using any deal’s gain distribution,
which shall reduce the promotable net gain, so GP shall take less carry in this case.
Losses can be categorized as below Realized Loss and Unrealized Loss, which is
explained below.
During the loss recoupment user can choose to recoup any type of loss. Distribution
can recoup the loss based on configuration. List of option: FIFO, LIFO, HIFO, Manual
Recoupment.
2.8.6.1 Realized Loss

Underperforming deals are booked as permanent loss in the book. This loss portion
cannot be reverted back. This type of losses can be recouped any time during the
distribution, which would decrease the promotable net gain.
Writedown: Writing down the investment shall create the temporary loss, this may
come up later.
Sold less than Cost: If a deal is sold less than its cost, it introduces the realized loss
of an investment.
2.8.6.2 Unrealized Loss

Underperforming deals are booked as a temporary loss, which can come back later at
any point. This type of losses can be recouped any time during the distribution. But,
when the deal start performing well, recouped unrealized losses can be reversed,
which would increase the promotable gain for the distribution.
2.9 Export to Source System

2.9.1 JE output to Source System
Once the waterfall numbers are calculated, WFE application must post the result
back to Investran as Journal Entries.
Below are the lists of methods to post the JE to Investran:
Page 50 of 62 14-Sep-23
Version : 4.3
2.9.2 Output Mapping for Source System

WFE generates waterfall output as Journal Entries, which shall be booked back into
Investran. Booking the JE back to Investran shall be based on the WFE Data Point to
Investran Output Transaction mapping.
This mapping shall be done as part of Waterfall Definition.
Below is an example of the mapping:
Source System Transaction Type Mapping

WFE Data Point
Credit Account Debit Account
Sale – Catchup Waterfall: LP Split Waterfall: GP Split
Sale - Preferred Return Waterfall: Preferred Return (CR) Waterfall: Preferred Return (DR)
System shall allow the user to allocate the WFE Data Point value to multiple deals /
positions / lot based on logic defined by the user. Below is an example of such an
allocation logic:
 Remaining Invested Capital
 Gain produced by the Deal/Position/Lot
2.9.3 Data push Options to Investran

WFE application generates the waterfall numbers based on the input received from
Investran, which shall be posted back into Investran. Investran provides below two
options to post data back from external application like Haervest:
 Investran SDK
 Investran DIU (Data Import Utility)
2.9.3.1 Investran SDK

Investran provided .NET based API’s to interact with investran’s functions. KKR shall
develop a web service using the SDK API’s, which shall be used by WFE application
to post the Waterfall Output Journal entries in to Investran.
2.9.3.2 Investran DIU (Data Import Utility)

Investran provided DIU to import transactions in bulk. WFE shall generate waterfall
output journal entries as excel spread sheet, which can be imported in Investran
using DIU.
2.10 Reporting
WFE will produce all data points at the most granular level i.e. for a given Specific
Investor, each data point will be at the Position level and if applicable, at the Tax Lot
level. There are 3 approaches to reporting on data in Haervest:
1. Ad hoc reporting in Haervest

2. Push the data to the Enterprise Data Warehouse and use an Ad hoc tool
3. Canned reports in Haervest, produced using Crystal Reports or Cognos
Ad hoc reporting in Haervest
Page 51 of 62 14-Sep-23
Version : 4.3
Given that WFE will produce granular data points, it may be possible to attach an Ad
hoc query builder tool to the WFE data store and allow the users to generate their
own reports. This possibility has to be further researched by KKR along with the
decision on a suitable tool. Further, it is to be noted that the WFE database schema
is best suited for transactional data where the schema is required to be highly
normalized. However, for ad hoc reporting, this highly normalized structure has to be
transformed into a flat aka de-normalized structure. This has to be handled as a
separate task, involving specialized IT resources.
Push the data to the Enterprise Data Warehouse and use an Ad hoc tool
When the KKR Enterprise Data Warehouse is available for the WFE system, the
granular data points can be pushed to the warehouse to allow the user to create
canned or ad-hoc reports using a reporting tool to be recommended by SAE.
Canned reports in Haervest, produced using Crystal Reports or Cognos

In addition, if required, reports can be created directly out of Haervest. The design
and development of these reports will be taken up as separate items when the
reporting requirements have been finalized.
Following is the set of reports identified during the preparation phase of this project.
These reports will be built as canned reports using Crystal Reports or Cognos
reporting tool and made available in the WFE system. In addition, any data in a
tabular format will be allowed to be exported to Excel.
# Report Name Description

1 Income Only Waterfall Display all the tier target and paid
2 Income and Sale Waterfall Display all the tier target and paid
3 Carry Report Unrealized report shall be generated during period
close.
4 Giveback Details Giveback calculation details, which shall display the
numerator records and denominator records.
5 Preferred Return Details Preferred return calculation details, which shall display
all the contribution and distribution records along with
the pref start, end date and eligible base amount
6 Loss Recoupment Details Loss recouped as part of current distribution shall be
displayed
7 IRR – Fund – Gross
8 IRR – Fund – Net
9 IRR – Partner – Gross
10 IRR – Partner – Net
11 Ability for the user to review
life to date gross of carry
investment proceeds by
investment and by date
life to date net of carry
distributions by investment
and by date
Page 52 of 62 14-Sep-23
Version : 4.3
life to date net of carry

investment proceeds by
investment and by date
14 Ability to report on break
even FMV to avoid clawback
15 Ability to report on
Hypothetical Clawback
16 Ability to report on maximum
clawback
17 Audit report - user
interaction, source data
arrival, stack ordering,
execution, reverse/delete
requests etc
18 Waterfall Definition Report
by Investor (Shows each tier
configuration and formulas)
19 Ad-Hoc query builder Query tool to be determined by KKR (SAE)
2.11 Projection and Scenario (requirements pending – delayed to

later iterations)
Projection and Scenario modeling is a feature that is meant for the user to perform
what-if analyses. The high-level concept is that the user shall be allowed to enter
hypothetical fund level events and have WFE create Specific Investor level
allocations based on the then current allocation percentage in the fund or in the
specific deal/position. These Hypothetical events shall be created on the basis of the
real events booked in Investran. The Waterfall process for the distribution events
thus created will be the same as that for the real distribution events i.e. user will be
able to create new Waterfall Definitions and apply them on the scenario events.
The principal purpose of this feature is to allow the user to simulate a gradual fund
close during the post investment period. It is to be noted that the ‘Hypothetical’
Waterfall Type will be used to simulate an abrupt fund close at the end of each
performance reporting period.
Page 53 of 62 14-Sep-23
Version : 4.3
3 USE CASE AND UI SPECIFICATION

Separate document created. Click the below link to access the document:
Use case & UI Specification
Page 54 of 62 14-Sep-23
Version : 4.3
4 LOGICAL DATA MODEL

4.1 Static Entities
Page 55 of 62 14-Sep-23
Version : 4.3
4.2 Business & Waterfallable Events
Page 56 of 62 14-Sep-23
Version : 4.3
4.3 Waterfall Group, Waterfall Definition, Waterfall Bucket and Tier

Formula
4.4 Waterfall Definition, Waterfall Bucket and Transaction Type
Page 57 of 62 14-Sep-23
Version : 4.3
4.5 Specific Investor & Waterfall Definition
Page 58 of 62 14-Sep-23
Version : 4.3
4.6 Client, Fund Family & Source System Database
Page 59 of 62 14-Sep-23
Version : 4.3
5 NON-FUNCTIONAL REQUIREMENTS
5.1 Performance Requirement (TBD during QA)
For a given Waterfall execution, the response time of WFE will be a function of the following:
1. Fund’s vintage
2. # of events (inception to date count of business and waterfall events)
3. # of Investors
4. Variability in the waterfall process among the Investors
It is difficult to assess the response time of the system during the functional design phase.
The proposal is to ensure that each component of the system will be built to perform its unit
of work in the least amount of time that is possible. To address performance bottlenecks,
scalability and parallelization of processes have been discussed in the Technical Architecture
document.
There will be a period set aside in the development cycle where the ThoughtFocus QA and
the KKR users will assess the performance of the system in terms of response time.
Page 60 of 62 14-Sep-23
Version : 4.3
6 OUT OF SCOPE
Multi Currency: WFE will be currency agnostic. All currency related calculation will be
handled in the source system.
Multi Lingual: System content will be shown in English only.
Page 61 of 62 14-Sep-23
Version : 4.3
Appendix A. Issues List
Page 62 of 62 14-Sep-23

FunctionalDesign Sample

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FunctionalDesign Sample

Uploaded by

Copyright:

Available Formats

WFE - Functional Design Document

Current Version 4.3

3.0 5/2/2014 RP 2.2.3, 2.2.41

 2.3.4: Fund on-boarding Flowchart added

1.3 Reference Documents...............................................................................................7

1.4 Abbreviations and Acronyms...................................................................................7

1.5 Current System Summary........................................................................................8

2.1 Haervest Functionality Summary.............................................................................9

2.2 Source System Data Specification...........................................................................9

2.3 Waterfall Configuration (Fund Setup)....................................................................20

2.3.3.4 Management Fee Giveback Tier................................................................................................23

2.4 Event Review & Waterfall Execution......................................................................33

2.5 Waterfall Output Review & Approval.....................................................................35

2.6 Role Based Security................................................................................................38

2.7 Business Process Flow and Haervest Workflow..................................................43

2.8 Waterfall Calculation...............................................................................................44

2.8.3 Preferred Return Calculation............................................................................................ 46

2.9 Export to Source System........................................................................................49

3 USE CASE AND UI SPECIFICATION................................................................53

4 LOGICAL DATA MODEL....................................................................................54

4.1 Static Entities........................................................................................................... 54

4.2 Business & Waterfallable Events...........................................................................55

4.4 Waterfall Definition, Waterfall Bucket and Transaction Type..............................56

4.5 Specific Investor & Waterfall Definition.................................................................57

4.6 Client, Fund Family & Source System Database..................................................58

5.1 Performance Requirement (TBD during QA).........................................................59

APPENDIX A. ISSUES LIST....................................................................................61

1.3 Reference Documents

1.4 Abbreviations and Acronyms

1.5 Current System Summary

WFE application functionality can be categorized as below:

2.2 Source System Data Specification

2.2.1.2 Fund Family

2.2.1.3 Legal Entity

2.2.1.4 Investor (Common Investor)

2.2.1.5 Specific Investor

Specific Investors are categorized as below:

2.2.1.6 KKR Common Investor

2.2.1.9 Tax Lot

2.2.1.10 Static Data Entity Diagram

2.2.1.11 HDS for Static Data

Deal & Position related static data:

Transaction Type & GL Account related static data:

2.2.1.12 Investran UDF Fields

UDF Field Name Description

2.2.2 Source System Transactional Data

In Investran data is stored in below hierarchy:

2.2.2.2 Journal Entry

2.2.2.3 GL Account (General Ledger Account)

Below is the GL Accounts list from Investran:

Below is the sample Transaction Type from Investran:

2.2.2.5 Investor Allocation

2.2.2.6 Investran Waterfall Estimation

2.2.2.7 Business Events Entity Diagram

2.2.2.8 HDS for Transactional Data

2.2.3 Upstream System Dataflow Options to Haervest

2.2.3.1 Data from Source System

Transaction data shall be pushed to WFE database periodically as well as on

2.2.3.2 Source System User Access Data

2.2.3.3 On-Demand Data – Push request from WFE Application

2.2.3.4 Entity Data Change Management and Versioning

Below are the different type of changes and action in Haervest:

2.3 Waterfall Configuration (Fund Setup)