Relationships between counterparties

A relationship links two counterparties and says what one is to the other. Alex is a director of a company. Sam is a trustee of a trust. Jordan is a partner in a partnership, a member of a close corporation, an official of a stokvel, or the executor of a deceased estate.

Each link is a record in its own right. It has a type, a start, a set of dated properties, and an end. It is not a field on either counterparty.

Every relationship has two sides:

• The host is the counterparty the relationship is about — the company, the trust, the partnership, the estate.
• The participant is the counterparty who plays the part — usually a person.

The same link reads differently from each side. On Alex’s screen it reads “Director of”. On the company’s screen it reads “Has Director”.

Relationships are a licensed capability. If your organisation has not licensed them, none of these panels appear. See switching features on and off.

Where you find them

Relationships appear on the counterparty screen in two shapes, and both read the same records.

flowchart LR
    T1[Trustee of] --> R[Relationships panel<br/>every type, both sides]
    T2[Partner of] --> R
    T3[Executor of] --> R
    T1 --> P1[Trustees panel]
    T2 --> P2[Partners panel]
    T3 --> P3[Executors panel]

The Relationships panel is the general view. It lists every relationship this counterparty has, in both directions, whatever the type. It carries a Relationship column so you can tell them apart, and it is the right place to answer “who is connected to this party at all”.

A named panel is the same panel narrowed to one relationship type. Because every row is then the same kind of thing, the panel can show that type’s own columns — appointment date, percentage, office held. That is the reason to use one.

Which panels a counterparty type shows is configuration, so your organisation decides. A counterparty type that shows no named panel still shows every relationship on the general Relationships panel.

Below the table both panels draw the same links as a diagram, with the viewed counterparty in the middle. Expand a party on the diagram to see one more hop — who that party is connected to.

What a relationship type decides

A relationship type is a piece of vocabulary your organisation configures. It carries four things that shape what you can do.

The host and participant checks read the counterparty type’s family, not just its name. If your organisation splits companies into private, public and non-profit forms, a type hosted by “company” reaches all three.

Some types are symmetric — spouse of, for example — where the link means the same thing read either way. A symmetric type refuses a party linked to itself, and refuses the same pair entered a second time in reverse.

Establishing a relationship

1. Open the counterparty and select the panel you want.
2. Select Add Relationship. On a named panel the button names that relationship instead.
3. Choose the Relationship Type. On a named panel the type is fixed, and you choose the Direction — whether this counterparty is the host or the participant.
4. Search for and select the other Counterparty.
5. Fill in the properties the type asks for. Required ones must be filled.
6. Check the Review step, then select Establish.

The same relationship, of the same type, between the same two parties cannot be live twice. A second attempt is refused. Once the first has ended you may establish it again — people do rejoin boards.

A relationship in one direction does not create one in the other. Two companies may each hold shares in the other, and those are two separate records.

Establishing, changing and ending a relationship are all eligible for countersign, so your organisation can require a second pair of eyes on any of them.

The properties a relationship carries

Each type declares its own properties, and each is dated. An appointment date, a resignation date, a percentage, a marital regime, an office held — the type decides.

Properties fall into two groups:

• Start properties are captured when you establish the relationship. An appointment date is one.
• End properties are captured when you end it. A resignation date is one.

If the type marks a start property as required, you cannot establish the relationship without it. The same holds for a required end property when you end it.

Changing a property

Use Edit on the row’s action menu. You give the new value and an Effective date.

• A date of today or earlier applies straight away.
• A future date is a scheduled change. The panel keeps showing today’s value and marks the cell with a calendar icon naming the date the change lands.

While a change is still scheduled, the row menu offers three more verbs:

A change that has already taken effect cannot be cancelled — it is history now. To restate history, use Correct, which changes what the record has always said from that date. See value dating for how effective dates work across the platform.

Worked example

Alex is a shareholder of Harbourline Trading, holding 40 per cent. Today is 1 July 2026.

1. A clerk edits Percent to 60, effective 1 September 2026.
2. The panel still shows 40. The cell carries a calendar icon reading 1 September 2026.
3. The deal falls through. The clerk selects Cancel scheduled Percent. The holding stays 40, on 1 September and after.
4. Separately, a holding recorded as 60 from 1 April 2026 turns out to have been captured wrong. The clerk selects Correct Percent and enters 55. The record now reads 55 from 1 April 2026 onwards, and the correction is in the audit trail.

The percentages here are shareholding percentages, and every date is the date the value takes effect — not the date somebody typed it.

Ending a relationship

A relationship is Active or Ended. There is nothing in between. “Resigned”, “former shareholder” and “no longer a member” are all Ended, and the date it happened lives in the type’s end property.

1. Select End relationship on the row’s action menu.
2. If the type declares end properties, fill them in — a resignation date, an effective-to date.
3. Select End.

If the type declares no end properties, you get a plain confirmation instead.

An ended relationship stays on the panel, marked Ended. You cannot edit or schedule anything on it, because its future is closed. You can still Correct a value it carried, because correcting restates the past.

Standing behind the host’s debts

Some relationships are more than a record of who is who. Where a relationship type declares the participant jointly and severally liable, the participant stands behind the host’s debts, and their financial summary says so.

An ordinary partnership is the case this exists for. The firm is not a separate legal person, so each partner is answerable for the whole of the firm’s debt.

The line is derived, so:

• It appears on the participant’s summary, labelled with the relationship — for a partner, “Partner of”.
• It stays out of the participant’s own totals. It is what they stand behind, not what they owe on their own accounts, and counting it twice would overstate the book.
• It disappears the moment the relationship is ended. It follows the relationship’s status, not the dates in its properties — so if a partner has left, end the relationship rather than only recording a leaving date.
• The host’s own summary is untouched. The firm sees its debt directly and derives nothing.

Limited-liability and fiduciary links derive nothing at all. A director, a trustee, or a member of a close corporation is not personally answerable for the host’s debts, so those types leave this alone.

Worked example

Harbourline Partners banks with Woodgrove Bank and runs an overdraft. The firm owes 900,000 ZAR, of which 12,500 ZAR is in arrears. Alex is a partner, and holds no account of their own.

1. On the firm’s screen the 900,000 shows as the firm’s own balance, with nothing derived.
2. On Alex’s screen the direct totals are empty — Alex has no accounts.
3. Alex’s summary carries one derived line: Partner of Harbourline Partners, 900,000 owed and 12,500 in arrears.
4. Every other partner’s screen carries that same line. That is what joint and several liability means, and it is why the figure is not added into anybody’s own totals.
5. Alex leaves the firm. A clerk ends the partner relationship, and the derived line goes with it.

What your organisation configures

• The relationship types themselves. Their names, how each side reads (“Trustee of” against “Has Trustee”), which counterparty type hosts each one, and which counterparty types may participate.
• The properties each type carries. Their labels, whether each is captured at the start or at the end, and which are required. Adding a column to a relationship is configuration, not a release.
• Which types imply joint and several liability. This is what turns a relationship into an exposure line, so it is deliberate and per type.
• Which panels each counterparty type shows. Whether a trust gets a dedicated Trustees panel or just the general Relationships panel is your choice.
• Whether relationship changes need countersign, and who may make them at all.

See counterparty roles for the other way a counterparty attaches to something — a role against an account, rather than a link to another party.