---
title: "Intercompany tie-out — detailed mechanics"
sidebarTitle: "Intercompany tie-out"
description: "Why a one-sided intercompany result is almost always a location-coding error, the client's $100,000 materiality threshold, and how to run the report."
icon: "arrow-right-arrow-left"
---

> **For AI agents:** the complete documentation index is at [llms.txt](/llms.txt). Append `.md` to any page URL for its markdown version.

Run the **Income Intercompany and Tie-Out Report** for each balance sheet review, for all RCY (and correspondingly RRS) locations.

<Info>
  **Source:** `Rackson_RRS_RCY_Review_Process.docx` section 26.
</Info>

<Warning>
  Run this **as part of finalizing the balance sheet — not as an afterthought.**
</Warning>

## What the report is for

To confirm that intercompany postings between the RRS and RCY entities **net to zero**, or at minimum stay under the client's established materiality threshold of **$100,000**.

<Note>
  Mike specifically wants it kept below that level because **larger imbalances start to create uncomfortable questions** if a bank or other stakeholder were to ask about it.
</Note>

## Why a one-sided result is almost always a coding error

Mechanically, **Intacct requires a due-to/due-from source** whenever a transaction is posted that spans two different entities. You cannot simply post one side of an entry to one entity's location without the offsetting side automatically hitting the other entity — **provided the accounts and locations involved are correctly assigned to their respective entities.**

<Warning>
  Because of that structural requirement, **a one-sided result almost always indicates a location-coding error** — an entry posted to a location that is actually assigned to the wrong entity — **rather than a genuine, uncorrected intercompany imbalance.**

  In other words: the risk isn't that someone can post an unbalanced intercompany entry on purpose. **The risk is someone posting to the wrong entity's location by mistake.**
</Warning>

<Note>
  **Illustrative example.** The client's own period-end GL adjustment entries were occasionally the source of one-sided intercompany balances in past periods — an amount recorded on only one side of an intercompany relationship. **The client has since corrected the way those entries are prepared**, but this remains an area to watch each period.
</Note>

<Frame caption="Income Intercompany and Tie-Out Report in Intacct">
  <img src="/images/customers/rackson/review-process/image10.jpg" alt="Sage Intacct income intercompany and tie-out report" />
</Frame>

## Practical tip

<Note>
  **Default the report to run for RCY (or the applicable concept) locations** rather than leaving it on a default "all" view — **the location-specific version is what surfaces the actual coding issue.**
</Note>

## The underlying account

The intercompany balance is carried in acct **12505**: RRS holds a **debit** balance, RCY holds an **equal and opposite credit** balance, netting to **$0** as of period end.

Common sources of imbalance:

- Intercompany charges posted in one entity but not the other
- Timing of allocation entries
- **On the RCY side specifically:** labor allocations from the G&A reclass, shared service charges, or management fee accruals

<Warning>
  **Do not close the period with an imbalanced intercompany account.** Trace the imbalance to the most recent intercompany activity or G&A allocation and post offsetting JEs before submitting finals.
</Warning>

## Related

- [RRS receivables workpapers](/internal/customers/rackson/workpapers/rrs-receivables) — the 12505 preparer steps (RRS side)
- [RCY GL adjustments workpapers](/internal/customers/rackson/workpapers/rcy-gl-adjustments) — the 12505 preparer steps (RCY side)
- [Labor reclass and bonus](/internal/customers/rackson/review-process/labor-reclass-and-bonus) — the G&A allocation that most often causes an imbalance
- [Troubleshooting](/internal/customers/rackson/review-process/troubleshooting) — "the intercompany tie-out isn't at zero"