Phase 6 (group consolidation): questions for the adviser, rulings for the owner

Prepared 2026-10-04 from the repository at 6ebc7752. Part A can be sent on its own. Part B is for the owner.

Nothing here is a legal or accounting conclusion. Where a rule is described as “as we understand it”, that is the author’s recollection, not read from the Act or the standard, and is offered only so the adviser can correct it. “Recommended default” means what the system will do or show until answered, and is the engineering team’s choice, not advice.

PART A. For the external adviser (accountant / company secretary)

Context in four lines

An organization on our ERP (the “owner”) keeps a register of a corporate group: entities (companies and individuals), dated shareholdings, approved judgments about control and influence, beneficial owners, and consents from member organizations that let the owner read their books. The register derives relationships for any date from the shareholdings, and labels every derived result presumed until a second person approves a written assessment. Stage 1 (the register) is built. Stage 2 (consolidation runs and eliminations) is a draft design; nothing is built. Until you answer, every output is labelled a “management view”, never statutory accounts.

Wording the screens use today (en), for reference in the questions:

Where	Exact text
Derived legal result	“Presumed subsidiary (not assessed)” / “Presumed not a subsidiary (not assessed)”
Derived control result	“Presumed control (not assessed)”
Derived influence result	“Presumed influence (not assessed)”
After an approved assessment	“Subsidiary” / “Not a subsidiary”; “Controlled” / “Not controlled”; “Significant influence” / “No significant influence”; “Requires judgement”
Column / test headings	“Legal (Companies Act)”, “Legal (Companies Act s.4)”, “Control (MFRS 10)”, “Influence (MFRS 128)”
Beneficial-owner candidates	“Individuals at or above 20% of a company, directly or through a chain, with no declaration covering that day. Nothing is declared automatically.”

Each question has: System now (what is implemented, with its source), Answer changes (what we would alter), Until answered.

Sources: reg = docs/superpowers/specs/2026-10-03-group-register-design.md; con = docs/superpowers/specs/2026-10-03-consolidation-runs-design.md; derive.go = internal/platform/group/derive.go.

A1. Group register: legal and accounting tests

Q1. Companies Act 2016, section 4: when is one corporation a holding company of another?

System now (reg section 4 item 0; derive.go, RelationshipsAt): “presumed subsidiary” if any of: total voting over 50%; total ordinary-share ownership over 50% (preference shares excluded); the holder has a recorded board-control fact on a direct holding. Otherwise “presumed not a subsidiary”. Wording of the Act was taken from a note, not read.
Please confirm or correct: (a) the exact limbs (board composition, voting power, issued shares); (b) the exclusion of preference shares from the share limb, and the precise class that is excluded; (c) whether “voting power” counts every share class; (d) how indirect holdings count: we multiply ordinary percentages along any chain (60% of a company holding 50% is 30%) and pass voting through an entity only while it is itself controlled. Is that right, or must each intermediate be a subsidiary? (e) whether board control can arise indirectly (we read the flag from direct holdings only); (f) any other deeming rule we have missed (nominees, concert parties, rights exercisable only on a condition).
Answer changes: the formula in derive.go, and whether the label may read “Subsidiary” / “Not a subsidiary” when derived, not only when assessed.
Until answered: only “presumed” labels are shown; an approved legal assessment can still set the outcome.

Q2. MFRS 10 control: is “over 50% of voting, directly or through controlled entities” an acceptable derived presumption?

System now (reg section 4 item 1): above 50% total voting yields “Presumed control (not assessed)”. Control below 50% (de facto control, board appointment rights) or none above 50% (protective or restricted voting) comes only from an approved assessment with a written rationale and a second approver. Register spec marks MFRS content as checked; the consolidation spec marks the same standards (unverified).
Please confirm: the presumption is reasonable as a starting label; whether a derived label should ever appear without the words “not assessed”; what an assessment’s rationale must cover to be adequate evidence.
Answer changes: label wording, assessment rationale prompts.
Until answered: as above.

Q3. MFRS 128 significant influence: 20% of voting power.

System now (reg section 4 item 2): 20% or more voting, and not controlled, yields “Presumed influence (not assessed)”. The register lists every assessed override (20% or more judged not influential, or under 20% judged influential) under “Influence overrides to disclose”.
Please confirm: the 20% presumption and its direct-plus-indirect measurement; that overriding it is a disclosable judgment; whether voting alone is the right measure.
Answer changes: threshold constant, the disclosure list.
Until answered: as shown.

Q4. Beneficial ownership: Companies Act 2016, section 60A and the SSM guideline.

System now (reg section 4 item 3; derive.go): an individual is a “candidate” when total ordinary ownership or total voting, direct or indirect, is 20% or more of a company, and no declared beneficial_owner row covers the day. Candidates are listed, never auto-declared. Declared rows store the individual, subject, percent, nature of control and SSM lodgement date. The register spec cites section 60A and the guideline without marking them unverified; they are.
Please confirm: the threshold and its “or” between shares and voting; “indirect” measurement (multiplied product versus through controlled entities); the “ultimate effective control” limb (we cannot derive it from shares, so it is recorded by hand); what we must record about a person who ceases to be one, and for how long; the PDPA position on storing identity numbers (we mask them behind group.register.sensitive and audit every read).
Answer changes: candidate formula, fields recorded, retention of ended rows.
Until answered: candidates are a prompt only.

A2. Retention

Q5. Retention of accounting records, and which register records it reaches.

System now: the platform uses seven years as a working figure (docs/ROADMAP.md, “Seven-year retention outranks erasure (ITA s.82A)”; the owner confirmed seven years for payroll records on 2026-10-03). That reference is to the Income Tax Act. For the group register the plan (G2) records seven years as provisional. shareholding, relationship_assessment, beneficial_owner and group_access_grant grant the application no DELETE (db/migrations/00920_group_register.sql). company_group and group_entity do grant it, because “no retention ruling has been made” (internal/kernel/db/retention_test.go). Stage 2 would add runs, eliminations and inputs as retention-bearing (con section 9).
Please advise: (a) the period required under the Companies Act for accounting records, and whether it differs from the tax period; (b) when the clock starts (financial year end, transaction date, date of last entry); (c) whether each of these is an “accounting record” or a statutory register with its own period: shareholdings, beneficial-owner declarations (including ended ones), relationship assessments, consent grants, consolidation runs and their inputs; (d) whether a record of a deleted group or entity must itself be kept; (e) how erasure requests for beneficial-owner personal data interact with the period.
Answer changes: the retention constants, the list of undeletable tables (Part B item 1), the erasure path that does not yet exist.
Until answered: seven years, no delete path in code, no erasure path.

Q6. Duty to prepare group accounts, exemptions, and reporting basis.

System now (con section 11): not asserted. The design supports basis mfrs10 only; a group that reports under another framework (we recall MPERS for some private entities, unverified) cannot use a run as statutory accounts. Outputs carry a “management consolidation” banner.
Please advise: whether and when a Malaysian holding company must prepare group accounts, the exemptions, filing and audit obligations, and whether MPERS groups are in scope for us at all.
Answer changes: whether to add a second basis value, banner removal criteria.
Until answered: banner stays; no run is shown outside the owner’s team (con decision D16).

A3. Consolidation design: points marked “unverified” (con section 14, grouped by topic)

Not asked here: con section 14 items 6 to 9 (posting rules setting party_id, posted_seq, seeded chart codes, trial-balance closing exclusion). Those are engineering facts to verify in code, not adviser matters.

Inter-company eliminations (MFRS 10)

Q7. Elimination of intragroup balances, income, expense and dividends (con sections 6.4, 6.5).

System now: inter-company items are identified by an account tag plus a party mapped to a group member (both required), then eliminated at the matching amount per ordered pair, after translation. Receivable against payable, revenue against cost, interest, dividend income against dividend paid. A dividend paid to a non-controlling interest is not eliminated and reduces NCI.
Please confirm this treatment, and whether anything else must be eliminated in full (loans, management fees, guarantees).
Answer changes: the closed list of elimination kinds and their golden-file tests.
Until answered: designed as written; nothing built.

Q8. Tolerance for unexplained inter-company differences (con sections 6.5, 13 D13).

System now: a group-level tolerance, default zero, stored on the group and copied to each run. A difference that recomputing at a common rate removes is classed rate; any other is unexplained. An unexplained amount over tolerance makes the run provisional and unapprovable until an approver accepts it with a reason.
Please advise: whether there is an accepted practice or materiality guide for carrying or writing off differences, who may accept one, what must be documented, and how timing differences (goods or cash in transit) should be treated.
Answer changes: default tolerance, acceptance rules, classification names.
Until answered: zero tolerance, acceptance by a second person with a reason.

Investment elimination and goodwill (MFRS 10, MFRS 3)

Q9. Investment against equity and goodwill (con sections 6.3, 6.4).

System now: the parent’s investment is eliminated against the subsidiary’s equity at the acquisition date. Goodwill = consideration + NCI (measured as the owner records) - fair value of identifiable net assets. Fair values, contingent consideration and the NCI measurement basis are owner-entered, second-person-approved inputs, never inferred. A negative result (bargain purchase) is refused to a person. Impairment is an approved input, not computed. Goodwill of a foreign subsidiary is held in its currency and translated at closing.
Please confirm the formula and which inputs a trial balance cannot supply; the NCI measurement options we should offer; how pre-acquisition reserves are separated; what evidence supports a bargain-purchase conclusion; the impairment inputs.
Answer changes: the acquisition_record fields and the formula.
Until answered: as written; refusals are explicit.

Non-controlling interest (NCI)

Q10. NCI amount and attribution (con sections 7.3, 7.4).

System now: subsidiaries are consolidated 100% line by line. NCI = (1 - effective ownership) of net assets, adjusted for the recorded NCI basis, plus the same share of profit, other comprehensive income and the translation reserve. Effective ownership is the register’s ordinary-share product along chains; multi-level groups are processed bottom-up. Voting decides control; ownership decides attribution. Preference or multi-class structures are refused in v1.
Please confirm: attribution on ownership rather than voting; the chain product for multi-level NCI (including when an intermediate is not wholly owned); how preference shares and other classes should enter NCI, so we know what the refusal costs a typical customer.
Answer changes: the attribution formula and which structures are refused.
Until answered: as written.

Unrealised profit

Q11. Unrealised profit in stock (con section 6.6).

System now: profit on goods still in the buyer’s stock is eliminated in full; for an upstream sale by a subsidiary the elimination is shared with NCI; for a downstream sale by the parent it is borne by the parent. Whether goods remain in stock and at what margin is an approved input, not derived. Deferred tax on the elimination is a further input (MFRS 112) and not computed. Opening unrealised profit is reversed against retained earnings from the prior year’s approved inputs. For associates, only the group’s share is eliminated.
Please confirm each allocation; how deferred tax on eliminations should be captured; whether the opening reversal is right.
Answer changes: allocation logic, input fields.
Until answered: as written.

Foreign currency translation and the reserve (MFRS 121)

Q12. Rate classes and equity (con sections 5.1, 5.3).

System now: assets and liabilities (including goodwill and fair-value adjustments of a foreign operation) at the closing rate; income and expenses at the average rate; share capital and other equity at the historical rate of each movement; prior-year retained earnings as the sum of each year’s result at that year’s average rate.
Please confirm each class and the retained-earnings approach. Also confirm that using each member’s organization base currency as its functional currency is acceptable, or tell us what evidence of functional currency we should record.
Answer changes: rate class by account type, the historical-rate bookkeeping.
Until answered: as written.

Q13. Translation reserve (con section 5.3).

System now: the reserve is the balancing figure of the translated trial balance, shown in other comprehensive income and as a separate equity component, with the NCI share allocated to NCI. It is also computed analytically (opening net assets x change in rate, plus result x (closing - average), plus movements x (closing - rate at date)); a run is refused if the two differ by more than a rounding tolerance recorded on the run. Recycling on disposal is out of scope.
Please confirm presentation, the analytic cross-check, what rounding tolerance is reasonable, and the treatment we are leaving out.
Answer changes: the check formula, tolerance value, presentation.
Until answered: as written.

Q14. Average rate (con sections 5.2, 13 D3).

System now: the unweighted arithmetic mean of the daily resolved reference rates (Bank Negara published rates, MYR per unit, via MYR as the hub; owner overrides honoured; a day without a published rate takes the latest earlier one). Stored on the run with its method name. A currency with no usable rate for any day refuses the run. A reference rate older than seven days is refused for a single-day lookup.
Please advise whether this approximation is acceptable where rates do not fluctuate significantly, whether a monthly average is preferable, and when an average must not be used.
Answer changes: the method value (new methods are added, never silently swapped).
Until answered: unweighted daily mean, labelled as an approximation.

Q15. Intra-group monetary items and net investment (con sections 5.4, 13 D7).

System now: exchange differences on inter-company monetary items between entities with different functional currencies are not eliminated; a residual caused only by rates is labelled rate and left in the result. The net-investment-in-a-foreign-operation exception is out of scope.
Please confirm both statements, and how often the exception is likely to matter for SME groups.
Answer changes: the elimination step and the rate class.
Until answered: as written.

Period alignment and uniform policies

Q16. Differing period ends (con section 7.1).

System now: a member’s books are read as of the group’s reporting date regardless of its own year end. A member’s profit and loss is its movement from the period start to the reporting date excluding its own closing entries; earlier unclosed profit is treated as opening retained earnings. A member whose books are not closed at that date makes the run provisional, and its own fiscal-year dates are shown on the run.
Please advise: the permitted gap between a member’s reporting date and the group’s, adjustments for significant events in the gap, and whether our read-as-of approach is acceptable.
Answer changes: the refusal rule and the provisional criteria.
Until answered: provisional run, dates disclosed.

Q17. Uniform accounting policies (con section 7.1).

System now: the system does not detect policy differences (for example depreciation or inventory costing). The owner records an approved, dated policy adjustment with a rationale, applied in the member’s currency before translation.
Please confirm this is an adequate mechanism and what an adjustment should record.
Answer changes: the adjustment inputs.
Until answered: as written.

Associates and other standards

Q18. Equity method, joint ventures, separate statements (con section 7.5; section 14 item 4).

System now: an associate is one line on the balance sheet and one in profit or loss: cost, plus the group’s share of post-acquisition profit and OCI, less dividends and impairment, from the associate’s trial balance if it is on the platform and consented, otherwise from an approved input. Associate policies must match the group’s. Joint ventures (MFRS 11) are not supported. The parent’s separate statements (MFRS 127) are the owner’s own ledger.
Please confirm the single-line presentation and the input list, and whether excluding joint ventures is acceptable for our target customers.
Answer changes: associate inputs, scope statement.
Until answered: as written.

PART B. For the owner: four pending Stage 1 rulings

Stage 1 is built and not signed off (docs/ROADMAP.md, Phase 6). Each ruling below is independent. The recommendation is the engineering team’s, with reasons; none is required by the adviser’s answers except where noted.

B1. `DELETE` for `company_group` and `group_entity`

Current state: the application role has DELETE on both tables (it was revoked on the four retention tables only). No code path deletes either. No edit or rename path exists either (the service has create, get and list only). Foreign keys from the retention tables already stop a delete of any group or entity that has a holding, assessment, declaration or grant. internal/kernel/db/retention_test.go lists both under tables that may grant DELETE, with the comment “no retention ruling has been made”.

Option	What it means	Consequences	Code and test changes
1. Keep as is	Privilege stays; only empty groups and entities could be deleted by raw SQL	The AGENTS.md rule (retention-bearing tables must not grant the privilege that lets a record be erased) is not engaged only if these are not retention-bearing, which is exactly what is undecided (adviser Q5). A group will gain history in stage 2 (runs reference it), after which a delete is impossible anyway. If Q5 later says they are records, the privilege must be revoked on data that already exists	None
2. Revoke `DELETE` on both (recommended)	Treat group and entity as records; correct a mistake by creating a new one	Matches the append-only habit. A group’s existence is evidence of what a later consolidation relied on. Cost: a mistaken group name stays, and `UNIQUE (org_id, name)` on `company_group` blocks reuse of that name; there is no rename path today to soften it. An entity wrongly added cannot be removed (it can be left with no holdings)	New migration revoking `DELETE` on both; in `retention_test.go` move both names to the no-delete list and update the comment; a test that the privilege is absent, preceded by one showing it was present before the migration (presence before absence). Run the retention test and watch it fail once with the revoke commented out
3. Keep the privilege and add a guarded delete route	An owner may delete a group or entity that has no history; the foreign keys refuse the rest	Needs a permission, an audited handler, an `api/openapi.yaml` operation, errors, web UI and tests. The refusal for a group that a member’s grant points to would reveal to the owner that a grant exists (the owner cannot see it otherwise). Delete of a record that Q5 may call a record is the risk	All of the above plus route-authorization and label drift tests; the retention test is unchanged

Recommendation: option 2. It is the smallest change, it is consistent with every other retention-bearing table, it is cheaper to do before real data exists, and no feature depends on deleting. If mistakes prove common, add an “ended” state or a rename later as its own change (not assumed here). The adviser’s Q5 can only strengthen this, not weaken it, unless it says these are not records at all.

B2. Plain-column names versus translation rows for group and entity names

Current state: company_group.name and group_entity.legal_name are plain TEXT columns, 200 characters, and a CHECK refuses CJK characters (the record-language rule, architecture spec 11A.3: en and ms only). The rule in AGENTS.md is “every user-facing name is a translation row, never a column on the entity”. Precedent in the repo: party.legal_name and company_profile.legal_name are plain record-bearing columns with the same restriction; account names are translation rows (docs/superpowers/specs/2026-10-03-structured-account-codes-design.md). I did not find a drift test that flags a name column (search was not exhaustive).

Option	What it means	Consequences	Code and test changes
1. Keep both as plain columns	Names are record-bearing	Consistent with `party` and `company_profile` for a registered legal name. For a group’s own display name it departs from the invariant, and no `zh` display is possible (the CHECK forbids it)	None, plus a documented exception (ruling recorded in the spec)
2. Both as translation rows	Name per locale in `translation`; no name column	Honours the invariant. A legal name is a fact about a legal person, not a label; translating it is wrong, and the translation table is declared “configuration, not a record” with no delete (`retention_test.go`), a poor home for a statutory name. Uniqueness on name becomes a cross-table rule. Larger change in service, API, web, tests	New rows and migration, service and handlers read translations, openapi shape changes (generated client), web forms per locale, tests for fallback, unique name
3. Split (recommended)	`group_entity.legal_name` stays a plain record-bearing column. `company_group.name` becomes a translation row (en, ms, zh)	Follows precedent for legal names and the invariant for a user label. Smaller than option 2	Migration: add translation rows for existing groups, drop the column and its `UNIQUE (org_id, name)` (uniqueness moves to an application check or a unique index on the translation row for that entity kind, which must be designed); service, openapi, generated clients, web form and list; a test that a group with only an `en` name still shows (fallback)

Recommendation: option 3, with the caveat that it is the largest of the three and touches the contract. If the owner prefers the smallest change, option 1 with a recorded exception for the group display name is acceptable but then the AGENTS.md invariant has a named exception. Not determinable from the repo: how the translation table’s uniqueness would enforce “one group name per owner”.

B3. A shareholding immutability trigger

Current state: a change to a holding is a new row that ends the old (ruling GR-1), and the only UPDATE the code issues is setting effective_to (ChangeShareholding). But the application role holds UPDATE on every column, and the only trigger (shareholding_within_whole) checks the 100% cap, not immutability. So “the history a consolidation relied on can always be reproduced” (reg section 4) rests on code discipline, not the database. The same is true of relationship_assessment (approved once), beneficial_owner (ended once) and group_access_grant (revoked once); this ruling is about shareholding only, as the roadmap words it.

Option	What it means	Consequences	Code and test changes
1. Nothing	Rely on Go and on `DELETE` being revoked	Raw SQL or a future code path could rewrite a percentage and silently change a past consolidation	None
2. Trigger (recommended)	`BEFORE UPDATE` on `shareholding` refuses any change except setting `effective_to` on a row where it is null (once), to a date after `effective_from`	Database-enforced and binds the table owner too, unlike a privilege. The existing `shareholding_within_whole` still fires for the end-date update, and `ChangeShareholding` still works. Open point: should `source_document_id` be attachable after the fact? No path attaches it today, so the default is no	New migration; test with presence first (the end-date update is accepted) then absence (changing percent, voting, holder, subject, class, shares, board flags, `effective_from`, and re-ending an ended row are each refused); watch it fail once with the trigger dropped; Down migration; run `internal/platform/group` and `internal/kernel/db` tests
3. Column privilege instead	`REVOKE UPDATE` on the table, `GRANT UPDATE (effective_to)` to the app role	Fewer lines, no function. Does not bind the owner or migrations, and does not stop re-ending an ended row. Whether `retention_test.go` reads column-level grants correctly was not verified	Migration; adjust the retention test only if it misreads the grant

Recommendation: option 2, because the stated guarantee is about reproducing history and only a trigger protects it from every path. Follow-on question for the owner: apply the same pattern to the other three tables (a separate small change).

B4. `grantee_org_id` in the grant request

Current state: POST grant takes group_id, grantee_org_id and scope (internal/modules/group/handlers.go, makeGrant; api/openapi.yaml, makeGroupGrant). The member makes the grant and cannot see the owner’s register, so it names the owner’s organization id. The composite foreign key (group_id, grantee_org_id) -> company_group (id, org_id) refuses any organization that does not own the group (422 grantee_not_owner); an unknown group gives the same answer, so the call reveals nothing about groups. Reads of a member’s figures use the caller’s own session organization, never a request value (group_read_allowed).

Option	What it means	Consequences	Code and test changes
1. Keep (recommended)	Member states who may read	The member explicitly names the grantee, which is part of consent; the schema already makes a wrong value harmless. The member must obtain two ids (group and owner organization) from the owner out of band. Whether the owner’s screen helps by showing them was not checked	None (optionally document the out-of-band step in the UI)
2. Derive the owner from `group_id`	Drop the field; a new `SECURITY DEFINER` function returns the group’s owner	Easier for the member, but a new cross-tenant read: any organization could learn that a group id exists and who owns it, and the member grants to an owner it has not been shown. A function that also returns the owner’s name widens that further. Needs an allowlist entry, not executable by PUBLIC, and a presence-then-refusal test	Migration, allowlist entry, handler and service change, `api/openapi.yaml` and generated clients, web form, tests
3. Invitation flow	Owner issues an invite naming the group; the member sees the owner’s name before accepting	Best consent and usability, but a new table, expiry, permissions and screens: a feature, not a ruling	A new design and plan

Recommendation: option 1. The risk the roadmap item worries about (a wrong grantee) is already closed by the foreign key, and option 2 trades it for a new cross-tenant read. Revisit with option 3 only if the manual pass shows members cannot complete a grant.

Where the sources disagree (found while preparing this, none fixed here)

docs/ROADMAP.md, Phase 6 Stage 1 bullet: begins “BUILT (Tasks 1-6 …)” but ends “Spec: … Not built”. The tail is stale.
reg section 4 says Malaysian practice was “checked 2026-10-03” yet section 4 also says the s.4 wording and the retention period were not verified. Section 60A and the SSM guideline, and the MFRS 10 and 128 presumptions, are stated without the unverified marker that con puts on the same standards.
reg section 6 names shareholding and beneficial_owner as retention-bearing; the migration and plan also cover relationship_assessment and group_access_grant; company_group and group_entity are explicitly outside (Part B1).
The seven-year figure is cited in ROADMAP.md to ITA s.82A and confirmed by the owner for payroll only. The group plan calls it “provisional” (G2). No source ties it to the Companies Act.
con section 2.3 describes group_read_allowed(group, member, scope, as_of). The built function’s fourth argument is p_at timestamptz, the time of the call stamped on the audit row, not a reporting date (db/migrations/00921_group_read_allowed.sql). Stage 2 must not read it as as_of.
reg section 4 says the board-control fact is recorded “on the holding or the assessment”. derive.go reads it from holdings only, and only from the direct holding, so an assessment cannot add board control to the presumption (an assessed legal outcome overrides the presumption entirely).
The task brief refers to an execution record and open items in 2026-10-03-phase-6-group-register.md. On main the plan file ends at “Not in this plan” (96 lines); the open items are only in the roadmap bullet.