Six affiliates name their accounts six different ways — and the intercompany differences still come out sorted by timing, amount, and classification

Six companies, numbers scattered five ways

The lead's mission is clear: tie the books of six affiliates into one and produce K-IFRS (Korean International Financial Reporting Standards) consolidated financial statements. Consolidated financial statements are a report card that combines several legally separate companies and presents them as if they were a single company. The problem is that each family member keeps the ledger in a different format.

• The books of six affiliates. The goal is to tie them into one and produce K-IFRS consolidated financial statements
• SAP extracts. One company holds its data in SAP, an enterprise accounting system
• Excel files. Another company manages its books in Excel
• In-house web system entries. Still another company enters its data there
• Email attachments and groupware posts. What actually reaches the lead is often in this form
• Account names and transaction labels that differ per affiliate. Even for the same transaction the labels differ, so gathering the files into one place won't merge them as-is

33 Excel activities, leaning on human hands and eyes

The old way was repetitive Excel labor made up of four broad phases, with a total of 33 detailed tasks inside them. The first phase is collection: gathering SAP extracts, Excel files, and email attachments from six affiliates. The second is intercompany elimination — the "reconciliation" work of offsetting revenue and purchases, receivables and payables traded between affiliates. Within one family, an item the older sibling sold to the younger one isn't revenue for the family as a whole, so such transactions have to be singled out and erased. The third is consolidation adjustment: removing the profit attached to inventory not yet sold outside (unrealized profit), and offsetting equity method, investment, and capital. Only in the final, fourth phase are the financial statements confirmed.

Every one of these phases relied on human hands and eyes. Since each source had a different format and account definition, mapping and consistency-checking took enormous effort. When the two sets of books didn't match, deciding whether the difference was due to timing, amount, or classification leaned on the lead's experience. So it became a low-reproducibility task where the result wavered when the person changed. The outputs, too, were scattered across dozens of separate Excel files, making it hard to see at a glance how the whole thing fits together.

I spend all my time on the cleanup to get there, more than on the actual accounting judgment.

Load them into one workspace, formats and all

You don't unify the files up front. Once you put the six affiliates' data into one place in the workspace regardless of format, the agent takes over the job of mapping each affiliate's differing account names and transaction labels onto a common ontology, checking consistency — missing items, duplicates, format errors — and normalizing everything into an addable state. The translation work people used to do by hand ends right here. An ontology is a knowledge structure that attaches meaning to scattered data — "this is revenue, that's a receivable, these two are the same transaction" — and connects them to each other.

This is what you ask

"Find the revenue and purchases traded between affiliates where the two sets of books diverge"
→ A reconciliation that followed the connections between the data. The intercompany
   differences that diverge get pinpointed. Each one is sorted, by predefined rules,
   into a timing difference, an amount difference, or an account-classification
   difference.

"Recommend the consolidation adjustment entries for these differences and export to Excel"
→ Each difference gets a recommendation of which adjustment entry to make,
   output as Excel the staffer can use right away.

"Which source data and which adjustment did this consolidated revenue number come from?"
→ Not just the finished number: it unfolds the connections leading to it.
   On an entity page, hover a connection chip and the original sentence that
   grounds the fact is quoted as "{note} · line {n}".

The first question works because of what came before it. The labels that differ per affiliate are already mapped onto a common ontology, so graph matching that follows the connections between data replaces the step where a person used to line things up and compare them one by one. Classifying the cause of a difference moves into rules rather than the lead's experience. That's where reproducibility comes from: the same input yields the same result.

Once the adjustment-entry recommendations come out, the lead's role changes. The center of gravity moves from author — someone who produced the numbers from start to finish — to reviewer, someone who reviews and confirms the results the agent puts forward. Finally, aggregating the adjustment results on top of the ontology and visualizing them as K-IFRS consolidated financial statements puts the result and its basis together inside a single structure.

To keep a reconciliation conversation on the record, right-click that chat in the sidebar session list (or use the "…" button) and pick "Pin to case…". A "Pinned to a new case" toast appears with the number of entities pinned, and the chat and the recognized entities are bound together into a case.

What changes

Once six affiliates' SAP extracts, Excel files, and email attachments are loaded into one workspace, mapping and reconciliation, difference classification, adjustment-entry recommendations, and financial-statement aggregation all follow on from one another on top of the same ontology. That's as far as the PoC has confirmed.