Related Party Identification

By Nupur Mittal

Co-founder at OCTA — works with accounting firms on month-end close and reconciliation automation.

Related party identification is the process of building a complete list of an entity's shareholders, management, and affiliated parties, then scanning transactions to find every dealing with them — disclosed or not. Under ASC 850 (US GAAP) and IAS 24 (IFRS), any related party transaction that isn't on arm's-length terms, or isn't disclosed at all, is a reporting deficiency and a red flag for management override of controls. This page walks through the full identification and disclosure process, the red flags a careful reviewer watches for, and how accounting firms run the review faster with OCTA Flow while a human approves every finding.

Why related party identification matters, and where it goes wrong

Related party transactions sit at the intersection of two problems auditors and controllers worry about most: financial statements that don't tell the whole story, and insiders using their position for personal benefit. A loan to a shareholder, a consulting contract with a director's family member, or a lease with an entity the CFO happens to co-own isn't automatically improper — but if it's priced off-market, undisclosed, or approved by someone with a conflict of interest, it can misstate the financial statements, trigger tax exposure, and signal exactly the kind of override that shows up in fraud cases. Regulators and auditors treat related party transactions as a standing fraud-risk factor for this reason, not as a formality.

The practical difficulty is that related parties don't announce themselves on an invoice. A vendor called "Bright Path Consulting FZE" gives no hint that it's 100% owned by a director's spouse unless someone already knows that and thinks to check. Firms typically rely on management representations — a list someone in finance types up once a year — and then hope nothing important was left off. That's a thin control for something this consequential. A rigorous review cross-references ownership records against every GL transaction, tests pricing and approval on anything that matches, and actively hunts for the related parties nobody disclosed. The goal isn't just a list — it's a defensible answer to "did we miss anything," backed by evidence.

The related party identification process, step by step

A proper related party review follows a consistent sequence, moving from "who counts as related" to "what do we disclose." The steps below are the full procedure OCTA Flow executes; they also stand alone as a best-practice process any firm can follow.

1. Build the complete related-party list. Combine the shareholder register with management's related-party disclosures. Under ASC 850 (and materially the same under IAS 24), related parties include:

• Affiliates — entities under common ownership or control
• Principal owners — anyone holding more than 10% ownership — and their immediate family members
• Management — anyone responsible for achieving the entity's objectives — and their immediate family
• Other parties that can significantly influence management, or that management can significantly influence
• Employee benefit plans sponsored by the entity

For each party, document the name, the relationship type, the ownership percentage if any, and every associated entity name — a spouse's holding company, a sibling's LLC, a trust the CFO controls. This registry is the backbone of everything that follows; a gap here becomes a blind spot everywhere else.

2. Scan every GL transaction against the list. Compare the vendor or customer name (and the transaction description) on each general ledger entry to the related-party list. Match on exact names and on keyword/partial matches — abbreviations, "doing business as" names, and minor spelling variants all count. Any transaction that matches gets flagged as a related party transaction for review.

3. Read board minutes for anything the list missed. If board or committee minutes are available, look specifically for: approval of a transaction with a person or entity that isn't on the related-party list, references to loans made to officers or shareholders, and approval of compensation arrangements for key management personnel. Board minutes are often where an undisclosed relationship first surfaces, because someone in the room knew the connection even if it never made it onto a formal register.

4. Evaluate every flagged transaction on three tests. For each related party transaction identified:

• Is it at arm's length? Would an unrelated third party have gotten the same price and terms?
• Was it approved by disinterested parties? Did someone without a personal stake in the outcome sign off?
• Is it disclosed in the financial statements? Does the note disclosure already capture it?

Transactions at non-market terms may require a valuation adjustment or expanded disclosure. Loans to shareholders or officers carry their own exposure — disclosure is required regardless of amount, and off-market interest rates can trigger imputed-interest rules or be recharacterized as a constructive dividend.

5. Actively hunt for undisclosed related parties. Don't stop at confirming the list — look for what the list is missing:

• Vendors whose address matches an officer's home address
• Vendors with no verifiable online presence or business history
• Pricing or payment terms materially better than the terms given to unrelated vendors
• Circular payment patterns — the entity pays Party A, who pays the proceeds back to the entity or to another related party

6. Compare to the prior period. If a prior-period related-party disclosure exists, check that every party disclosed last year is still disclosed this year, and identify anything new. A related party that quietly disappears from the disclosure — without the relationship actually ending — is itself worth investigating.

7. Draft the required disclosure. For every material related party relationship and transaction, prepare the note language covering: the nature of the relationship, a description of the transaction, the dollar amount, any outstanding balance, and the terms of settlement. This is the deliverable a reviewer signs off on and an auditor tests against.

Worked example: a non-arm's-length transaction and its disclosure

Here's how a single flagged transaction moves from "unusual vendor name" to a finished disclosure.

The transaction. The GL shows a $120,000 payment coded to "Bright Path Consulting FZE" under professional fees, described as "Q1 strategic advisory." Bright Path doesn't appear on the management-provided related-party list.

What the review finds. Cross-referencing the shareholder register and public entity records shows Bright Path Consulting FZE is 100% owned by the spouse of one of the company's directors. That makes it a related party under ASC 850 even though nobody disclosed it as one.

Applying the three tests:

That combination — undisclosed, no arm's-length evidence, and approved by an interested party — is flagged high severity, because any one of the three would warrant a look, and having all three at once is a classic profile for management override.

The resulting disclosure note (illustrative):

Related Party Transactions. During the year, the Company paid $120,000 in consulting fees to Bright Path Consulting FZE, an entity wholly owned by the spouse of [Director Name], a member of the Company's board of directors. Management has not obtained independent evidence that the terms of this arrangement are consistent with terms that would be obtained in a comparable transaction with an unrelated party. The transaction was approved by [Director Name], who has a personal interest in the outcome. The Company had no outstanding balance payable to Bright Path Consulting FZE at year-end.

The fee itself isn't necessarily improper — the disclosure doesn't say it was wrong, only that it needs to be disclosed with the facts an outside reader would want. Whether it also needs a valuation adjustment or additional board action is a judgment call for the CFO, audit committee, or auditor — not something a review process resolves on its own.

Key controls and red flags

The difference between a related-party list and a reliable related party review is what you actively test for. A careful reviewer flags:

• Any related party transaction not disclosed in the financial statements — the single most serious flag
• Transactions at non-market terms — unusually favorable pricing, below-market or interest-free loans
• Large transactions with entities that share an address, phone number, or bank account with management
• Loans to shareholders or officers — a dividend-characterization and imputed-interest risk (US tax rules on below-market loans can impute interest income even when none was charged)
• Board approval of a non-arm's-length transaction with no independent sign-off
• New related parties in the current year that weren't on the prior-year disclosure
• Circular payment flows between the entity and a related party
• Vendors or customers with no verifiable independent business history

Catching these consistently — every period, not just at year-end — is what turns related party identification from a checkbox on a management representation letter into a genuine control.

What a completed related party review produces

A finished review isn't just a list of names — it's a documented workpaper a reviewer can sign off on and an auditor can follow. A complete related party review package includes:

How OCTA Flow automates related party identification

OCTA Flow does the cross-referencing and pattern-hunting for you and leaves the judgment — and the sign-off — with your team. The workflow mirrors the process above:

1. Pick the Related Party Identification Skill. Flow already knows the full procedure: build the related-party registry, scan every GL transaction against it, test for arm's-length terms and independent approval, and hunt for parties nobody disclosed.
2. Connect your data. Point Flow at the accounting system, or upload the period's files — the shareholder register, management's related-party list, and the GL transaction detail. Board minutes and the prior-period disclosure can be added for deeper coverage.
3. Run. Flow matches every GL transaction against the related-party registry using exact and keyword matching, tests each match for arm's-length terms and disinterested approval, and checks board minutes and address data for relationships nobody disclosed.
4. Review findings by severity. Instead of combing through every vendor name yourself, Flow surfaces only the transactions that need a decision — ranked by severity, each with a plain-English explanation and a recommended action: draft the disclosure, notify the auditor, route to the CFO or board for approval, or escalate to legal. Your team works the exceptions, not every line.
5. Sign off. Once the register is complete and disclosures are drafted, Flow assembles the workpaper with the full audit trail intact.

The result: the exhaustive name-matching and cross-referencing is done in a fraction of the time, and your people spend their hours on the handful of relationships and transactions that actually carry risk.

Control and trust: Flow proposes, you approve

This is what matters most to a firm putting its name on a disclosure that touches insiders and conflicts of interest: OCTA Flow never writes to your books or your financial statements on its own. Every disclosure draft, escalation, and recommended approval is a proposal that a human reviews and confirms before anything is finalized. Flow does the matching and the pattern-hunting and shows its reasoning; a person makes the call.

That control model runs through the whole review:

• Findings, not silent changes. Flow raises what it found and what it recommends — you decide whether a transaction is truly at arm's length, and how it should be disclosed.
• Severity and escalation built in. An undisclosed related party or a non-arm's-length transaction is flagged as critical or high and can be escalated straight to legal, the CFO, or the audit committee rather than sitting quietly in a spreadsheet.
• A complete audit trail. Every match, every proposed disclosure, every approval and override is logged — so when an auditor asks "how did you identify this," there's a documented answer.

You get the speed of automation with the accountability of human sign-off — exactly what a control this sensitive to conflicts of interest requires.

What the review draws on

To run a related party review, Flow uses the same sources a preparer already works from:

• Shareholder register — ownership percentages, related entities, and family relationships (required)
• Management's related-party list — the related parties already disclosed per management representation (required)
• GL transaction detail — the general-ledger transactions for the period, to scan for matches (required)
• Board minutes — for approvals or references that point to undisclosed related parties (optional)
• Prior-period related-party disclosure — to confirm continuity and flag new parties (optional)

Flow works from whatever your client has connected — it matches each input by its purpose, so it doesn't matter what the files are named or which system they came from.

Related skills and terms

Frequently Asked Questions

What is a related party transaction? A related party transaction is any transaction between an entity and a party that can influence, or be influenced by, that entity — shareholders holding more than 10%, management and their immediate family, affiliates under common control, or entities management can significantly influence. Under ASC 850 (US GAAP) and IAS 24 (IFRS), these transactions require specific disclosure regardless of whether the terms are favorable or unfavorable.

What's the difference between ASC 850 and IAS 24? Both require disclosure of related party relationships and transactions, and both use a similar definition of who counts as a related party. IAS 24 has somewhat more prescriptive disclosure requirements for management compensation and government-related entities; ASC 850 leaves more of that to judgment. In practice, a well-built related-party register and transaction test satisfies the core intent of either standard.

How do you identify related parties? Start with the shareholder register and management's own disclosures to build a complete list — including principal owners, management, their immediate family, and affiliated entities. Then scan every GL transaction against that list using exact and keyword matching, and independently check board minutes and vendor details for relationships nobody disclosed.

What makes a related party transaction "non-arm's-length"? A transaction is non-arm's-length when the price or terms differ from what an unrelated third party would have received — an interest-free loan, a fee with no comparable market benchmark, or payment terms materially better than what other vendors get. Non-arm's-length terms don't automatically mean something improper happened, but they require disclosure and often additional scrutiny.

What has to be disclosed about a related party transaction? The required disclosure typically covers the nature of the relationship, a description of the transaction, the dollar amount, any outstanding balance, and the terms of settlement. Loans to officers or shareholders require disclosure regardless of size.

Can related party identification be automated? The registry-building, GL scanning, and exception-flagging can be automated and reviewed, while the arm's-length judgment and disclosure decisions stay with your team. That's the model OCTA Flow uses.

Does OCTA Flow post entries or finalize disclosures directly? No. Flow proposes every disclosure draft and escalation; a person on your team reviews and approves before anything is finalized. Nothing is written automatically.

See how firms find undisclosed related parties faster, with human sign-off on every disclosure → start a 30-day OCTA Flow trial.