Skip to content

Decisions Log

Append-only. Every substantive decision gets a row. Never overwrite; if a decision is reversed, add a new entry that references and supersedes the old one.

Format

## YYYY-MM-DD — Decision title
**Decision:** what we decided
**Rationale:** why
**Alternatives considered:** what we didn't pick, and why not
**Status:** active | superseded by YYYY-MM-DD entry

2026-04-18 — Xero as accounting system of record

Decision: Xero for GL, balance sheet, and P&L. Forecasting layer (Fathom / Spotlight / Float) to be picked separately. Rationale: SMB-appropriate; official Brex integration already exists; Xero MCP server exists for future direct-from-Claude access. Alternatives considered: QuickBooks Online (comparable but integration with Brex is less developed); NetSuite (overkill for this scale); Sage Intacct (multi-entity strength, but no Claude MCP and priced at $400–800/mo vs. Xero $80/mo × 1 org). Status: active

2026-04-18 — Gitea as knowledge system of record

Decision: Self-hosted Gitea repo renfroe-holdings is the canonical knowledge base for all Renfroe Family Holdings and all subsidiary/affiliated entities. Rationale: Self-hosted beats cloud for sensitive financial data. Git gives free version history. Gitea MCP enables direct Claude Desktop access. Alternatives considered: Notion (has native Claude connector, but hosted and less ideal for sensitive data); plain filesystem (no version history, no collaboration primitives); Obsidian vault (reasonable but doesn't give the MCP-readable remote). Status: active

2026-04-19 — SUPERSEDES 2026-04-18 "Two Xero organizations" decision — ONE Xero org

Decision: Use one Xero organization for all US-side operations. Casa Moksha (RHG) and Renfroe Holdings GK keep their books with their local accountants (JME in Mexico; Japanese accountant in Japan) in local software for CFDI/SAT and Japanese compliance respectively. Monthly summary journals flow into the single Xero org under Renfroe Family Holdings with tracking-category segregation. Rationale: A second Xero org for RHG would duplicate maintenance without adding value — the accountant already works in Mexican software regardless (CFDI/SAT compliance requires it). Same for GK. Tracking categories provide the segregation. Alternatives considered: Two Xero orgs — the earlier choice — rejected once it became clear the foreign accountants don't use Xero and summary journals are sufficient. Status: active. Supersedes 2026-04-18 two-org decision.

2026-04-19 — Tracking categories: Entity + Asset Class

Decision: Two tracking categories in Xero. - Entity: Renfroe Family Holdings, W 3101, W 3603, ATX Marine, Austin Marine, Renfroe Marine, Five Points BHM, Oceana 433, Renfroe Hospitality Group (summary), Renfroe Holdings GK (summary) - Asset Class: Marina, Residential Rental, Commercial Rental, Hotel, Primary Residence, Holdings/Mgmt, Foreign Real Estate Rationale: Entity allows per-LLC P&L without fragmenting the COA. Asset Class lets us see "total marina P&L" or "all residential rentals" across entities — useful for performance analysis. Alternatives considered: Single tracking category (insufficient for analysis); three categories (overkill for a business this scale). Status: active

2026-04-19 — Intercompany transfers as capital contributions (within the disregarded stack)

Decision: When RFH funds a sub-LLC (or a sub-LLC sweeps to RFH), book as capital contribution / distribution. Do NOT book as loan. Rationale: All US entities are single-member disregarded — same taxpayer. No AFR, no interest, no tax event. Cleaner books. Exception: the AFR loan from Austin's parents to Five Points BHM IS a real loan and tracks as real debt. Alternatives considered: Intercompany loans with AFR interest (adds tracking overhead with zero tax benefit). Status: active

2026-04-19 — Intercompany transfers between RFH and RHG as intercompany settlements, NOT capital contributions

Decision: Wires from Brex/JPMorgan to Santander MXN are intercompany settlements clearing RFH's "Due to RHG" payable, NOT parent-to-sub capital contributions. Renfroe Hospitality Group recognizes all guest revenue (wherever received); RFH acts as collection agent for USD-denominated portion. Rationale: This reflects the economic substance: guests are booking with Casa Moksha (RHG), not with RFH. The "OWNER CONTRIBUTION" memo on Brex wires is Brex's autogenerated label, not the legal substance. Proper treatment depends on documenting an intercompany services agreement (pending). Alternatives considered: Treat as capital contributions from RFH to RHG (what the Brex memos imply) — rejected because it misrepresents the economic substance and creates transfer-pricing problems. Status: active. Intercompany services agreement drafting needed to fully document.

2026-04-19 — Historical Brex backfill to January 1, 2024

Decision: Pull Brex transaction history to Jan 1, 2024 for Xero import. Two full prior years + YTD provides comparables. Rationale: Brex direct-sync backfill limited to ~90 days; CSV import handles the longer history. Pre-2024 is diminishing returns (Brex account opened Oct 18, 2024 anyway, so "pre-2024" is mostly moot). Alternatives considered: Start fresh from Xero go-live (loses YoY comparability); pull further back (doesn't exist — Brex account opened Oct 2024). Status: active

2026-04-19 — Casa Moksha SBA payments as personal (not Five Points) liability

Decision: The monthly $7,965.60 SBA EIDL payment from Five Points BHM's Brex account (5803) books as a distribution from Five Points to Austin, and simultaneously as Austin's personal payment of his guaranteed debt. Five Points does NOT carry the SBA liability on its balance sheet. Rationale: Five Points BHM purchased the defunct 1006 20th St S LLC's senior (ServisFirst) note and paid it off. Five Points owes nothing to the SBA. The SBA has an uncollateralized note against defunct 1006; Austin's personal guarantee on that note is what makes him pay. Technically this is his personal obligation, not Five Points'. Alternatives considered: Book SBA as Five Points' liability (incorrect, Five Points is not the obligor); stop paying (SBA would pursue Austin personally). Status: active. Pearce Bevill to confirm treatment (see tax/2025-filing-prep.md Q13).

2026-04-19 — Casa Moksha revenue channels kept multi-routing, intentionally

Decision: Guest revenue will continue to land in any of: Brex Casa Moksha Dep (USD wires / PayPal / Stripe-style), Santander MXN (for guests paying local currency), PayPal (Casa Moksha), and (historically) Wells Fargo 6248. Plus the new Casa Moksha Coinbase for crypto. Rationale: Different guests have different preferences; forcing a single channel would lose bookings. Intercompany agreement handles the accounting cleanly. Alternatives considered: Single channel (simpler accounting but worse booking conversion); drop Santander MXN (would require Mexican guests to wire internationally, a real operational friction). Status: active

2026-04-19 — Amex direct feed + Plaid for non-Amex card ingestion

Decision: Amex cards connect to Xero via the native Amex direct feed (free, automated daily). Non-Amex cards feed via a Plaid → Python → Xero pipeline built out of band (~$0.30–0.60/card/month). Rationale: Native Amex is free and reliable. Plaid is the standard aggregator for everything else. Alternatives considered: CSV imports monthly for all cards (free but manual); Monarch-style aggregator as intermediary (loses accounting granularity). Status: active. Pipeline to be built as part of Tier 2 setup.

2026-04-19 — Xero-vs-Monarch data scope

Decision: - Xero contains: all operating entities, all real estate, all debt, all business credit cards, intercompany balances, Casa Moksha and GK summary journals - Monarch contains: personal lifestyle accounts, VC fund positions, convertible notes, direct investments, retirement accounts, crypto, vehicles Rationale: Xero is a general ledger for business activity; Monarch is a position tracker for net-worth visibility. Don't conflate. Alternatives considered: Put everything in Xero (investment positions that don't transact add noise without value); put everything in Monarch (Monarch can't do accrual accounting, depreciation, or tax-ready reports). Status: active

2026-04-19 — Monarch historical archive strategy (hybrid: Gitea archive + RFH subset to Xero)

Decision: Three-pronged treatment of Monarch's historical transaction data: 1. Full Monarch CSV export → source-data/monarch/ in Gitea — every account, every category, every year Monarch has. Purpose: disaster recovery / historical reconstruction. Re-exported at least annually. 2. RFH-side subset → Xero — only accounts owned by Renfroe Family Holdings or its disregarded sub-LLCs get imported as pre-feed backfill into the single Xero org. Monarch's reach (12 mo most, 18 mo for Chase) fills gaps before direct feeds took over. 3. RENFROE-side subset → held in source-data/monarch/ as a separate file — ready to seed RENFROE's books whenever that S-corp's accounting system is stood up. NOT imported to the RFH Xero org (RENFROE is a separate taxpayer — critical fact #11). Rationale: Serves the disaster-recovery goal (full history in versioned, self-hosted git) AND keeps the RFH Xero org's books clean (no personal / no separate-taxpayer data). Avoids spinning up a second Xero "personal archive" org and its subscription. Alternatives considered: - (A) Everything into RFH Xero tagged Entity=Personal — rejected; pollutes the LLC's books, weird look if audited, bulks every report until filtered, one miscategorized row leaks personal into LLC statements. - (B) Separate Xero "personal archive" org — rejected; adds subscription and runs counter to the consolidation we're doing (Moksha → RFH). - (C) Gitea archive only, nothing to Xero — rejected; loses the RFH pre-feed backfill benefit. Status: active. Supplements (does not supersede) the 2026-04-19 Xero-vs-Monarch scope decision: Monarch is still the live system for personal positions; this decision is specifically about historical CSV data.

2026-04-19 — Xero API integration via Custom Connection (not Web App)

Decision: Build Claude's Xero CLI toolkit (scripts/fpa/xero_client.py) on top of a Xero Custom Connection using the client-credentials OAuth2 grant. Development proceeds against the free Xero Demo Company; once validated, Austin pays the $10 USD/month Custom Connection fee to add a second connection bound to the real Renfroe Holdings, LLC org. Rationale: Web App integration (authorization-code + refresh token flow) was attempted first but Xero silently restricted half the scope set — accounting.transactions, accounting.transactions.read, accounting.reports.read, accounting.journals.read all returned unauthorized_client / Invalid scope for client at the authorize endpoint. accounting.contacts and accounting.settings worked. The failing scopes all touch ledger / reporting data; the working ones are reference-data only. Most likely cause: the Demo Company still linked to Austin's Xero user account (couldn't be unlinked from the UI) poisoning the scope set available to any Web App under that user. Custom Connection bypasses this — scopes are pre-declared in the Xero developer UI and don't consult user-level restrictions. All previously-failing scopes verified working (Organisation, Accounts, Reports/TrialBalance all return data) against the Demo Company on 2026-04-19. Alternatives considered: - (A) Persist with Web App and chase Xero support to unlink the demo — rejected; unclear timeline, possibly requires going through certification, and Custom Connection is a cleaner architecture for headless server-side use anyway. - (B) Custom Connection to the real RFH org immediately — rejected as first move because it commits to $10/mo before validating the toolkit end-to-end. Validate against Demo first. - (C) Use the community Xero MCP server via Claude Desktop — not an option here because Claude Code's Remote Control is the harness and MCP isn't wired through it; also a direct Python client is more testable and more portable. Status: active. Demo Company connection in use for dev; real org connection pending Austin's $10/mo subscription when Tier 1 (Xero setup) begins. Traefik route xero-auth.austinrenfroe.com and the xero_auth.py browser-flow script built during the Web App attempt have been removed; the Cloudflare DNS record remains for possible future use. Xero Web App developer entry deleted.

2026-04-19 — Casa Moksha Coinbase account going forward

Decision: Austin set up a dedicated Casa Moksha Coinbase account (2026-04-19), crypto-only, to replace the historical ad-hoc Coinbase (CM) that was actually RFH's. Future crypto-denominated revenue or payments for Casa Moksha will route through this account exclusively. Rationale: Clean entity separation. Avoids the intercompany overhead that was needed for the one-off Bitcoin retreat in Dec 2025 / Jan 2026. Alternatives considered: Keep using the RFH Coinbase with intercompany clearing (more accounting overhead every time). Status: active

2026-04-20 — Archive Brex-connector duplicate bank accounts in Xero (first live write)

Decision: Archive the 10 Brex business account / Brex business account#001-#009 ledger accounts in the live Renfroe Holdings Xero org. Keep the parallel user-named accounts (Casa Moksha: Dep, W 3101 Holdings, Oceana 433: Ops, etc.) as the authoritative ledger side for each of the 10 Brex cash sub-accounts. Rationale: Brex's native Xero connector auto-created Brex business account#NNN entries using BREX #### last-4 numbering in parallel with user-named accounts Austin had already added for the same Brex sub-accounts. Verified 2026-04-20 by pulling /v2/accounts/cash from Brex (see scripts/fpa/brex_client.py): Brex's own account names match the user-named side exactly, so the BREX #### side is redundant noise from the connector's default naming. Journal analysis at the time of archive showed zero activity posted to any of the 10 duplicates, so no transaction migration was needed. Executed via scripts/fpa/xero_cleanup_brex_dupes.py --execute — all 10 archived successfully on first attempt (no Brex-feed rejection). Reversible via Status: ACTIVE POST if a problem surfaces. Alternatives considered: - (A) Keep the BREX #### side, delete the user-named side — rejected; user-named matches Brex's actual names and matches the COA plan's 1010-1099 Cash and equivalents naming convention. - (B) Merge activity between the two sides — moot; all 10 duplicates had zero activity. - (C) Leave both sides in place — rejected; going forward, we want a single authoritative bank-ledger row per Brex sub-account so Brex transactions route to the correct place, not double-bookkept. Status: active. AccountIDs of the archived duplicates recorded in commit b705002. Next: add the 2 Brex sub-accounts missing from Xero (W 3603 3636, Austin Marine Holdings: Ops 9975).

2026-04-20 — Add 2 Brex-missing bank accounts to Xero (W 3603, Austin Marine)

Decision: Created the 2 Brex cash sub-accounts that existed in Brex but not in Xero. Both added with shape matching the existing user-named Brex sub-accounts (Type=BANK, BankAccountType=BANK, CurrencyCode=USD, no Code). - W 3603 (last-4 3636) — AccountID 04069bda-9083-4d3d-84bb-1e9a18e839da - Austin Marine Holdings: Ops (last-4 9975) — AccountID f7c3c97b-c7a3-4310-a347-6cca4f126cde Rationale: Closes the 13-in-Xero-vs-15-in-Brex gap found in the 2026-04-19 baseline. COA codes left blank to match the existing pattern; a single pass to assign 1010-1099 Cash and equivalents codes across all 15 Brex accounts will happen after JME/Japanese accountant/Pearce inputs unblock the final COA (per chart-of-accounts.md). Alternatives considered: - (A) Let Brex's connector auto-create them — rejected; that's what produced the BREX ####-named duplicates we just archived, so it would reintroduce the same naming noise. - (B) Add with full COA codes now (1021, 1030) — rejected; inconsistent with the other 13 Brex sub-accounts which currently have no Code. Assign codes in one cross-account pass when COA is finalized. Status: active. Executed via scripts/fpa/xero_add_missing_brex_accounts.py --execute. Next: Austin enables the Brex→Xero connector sync for these two accounts in Brex's integration settings so transactions flow.

2026-04-20 — Install Entity + Asset Class tracking categories in Xero

Decision: Created both tracking categories from the 2026-04-19 decision, with all options pre-seeded. - Entity (id 54dc4d83-ff14-436d-9f2a-cd2b0ae355c0) — 10 options: Renfroe Family Holdings, W 3101 Holdings, W 3603, ATX Marine Holdings, Austin Marine Holdings, Renfroe Marine Holdings, Five Points BHM, Oceana 433, Renfroe Hospitality Group, Renfroe Holdings GK - Asset Class (id 6a2607dc-96e2-4668-b459-42ce395753a1) — 7 options: Holdings/Mgmt, Residential Rental, Commercial Rental, Marina, Hotel, Primary Residence, Foreign Real Estate Rationale: Unblocks per-entity and per-asset-class reporting in Xero before any transactions post. Closes the 2026-04-19 baseline finding that the org had zero tracking categories despite the 2026-04-19 decision calling for two. Alternatives considered: Seed only the categories, let options accrue organically — rejected; we already know the full set and leaving options empty forces ad-hoc creation during coding. Implementation note: Xero's API rejects inline Options on category create ("Use the Options SubEndpoint"). Script does a two-step PUT: category first, then one /TrackingCategories/{id}/Options PUT per option. Documented inline in scripts/fpa/xero_add_tracking_categories.py. Status: active. Executed via scripts/fpa/xero_add_tracking_categories.py --execute; 2 categories + 17 options created, 0 failures.

2026-04-20 — Add Mexican IVA tax rates to the RFH Xero org

Decision: Four IVA rates added for use on RHG-related bills and sales that flow through the RFH Xero org (summary journals from JME, intercompany recharges, the handful of USD bills issued directly against RHG). Xero US auto-assigned TaxTypes: - IVA 16% (Purchase) — TAX003 (for bills RHG pays, mapped to account 1220 IVA recoverable per chart-of-accounts.md) - IVA 16% (Sales) — TAX004 (for sales RHG issues, mapped to account 2110 IVA payable) - IVA 0% (Zero-rated) — TAX005 (exports, taxable at 0%) - IVA Exempt — TAX006 (exempt supplies) Rationale: Casa Moksha charges 16% IVA (central-Mexico standard rate, not the 8% border zone). Purchase/Sales are separated by name — not by ReportTaxType — because Xero US orgs don't accept ReportTaxType values (INPUT/OUTPUT/etc. are UK/AU-only). Direction is inferred from Bill-vs-Invoice at posting time, but the name prefix lets the tax report segregate the two legs cleanly. Alternatives considered: - (A) Single IVA 16% rate and rely on Xero's direction inference alone — rejected; auditors expect the tax report to show recoverable vs. payable as distinct lines, not inferred from context. - (B) Add ReportTaxType=INPUT/OUTPUT — attempted; Xero US rejects with "The report tax type is not valid for this organisation". US orgs have a different, auto-assigned ReportTaxType taxonomy. Status: active. Executed via scripts/fpa/xero_add_mxn_tax_rates.py --execute; 4 rates created, 0 failures. No MXN transactions will post against these until JME summary journals start.

2026-04-20 — Merge Portilla contact duplicates + void $5,250 of double-keyed bills

Decision: Consolidated the two Portilla Ruy Díaz contact records into the accented canonical form and voided 3 duplicate bills that had been re-keyed on the dup contact. - Canonical kept: PORTILLA, RUY-DÍAZ & AGUILAR, S.C. (ContactID 4e028e3c-66e7-4a9c-9dba-abac89452ebc) - Duplicate archived: Portilla Ruy Diaz y Aguilar SC (ContactID 1ba94ab9-3f9f-4538-a8ec-42a3eabdfc4d) - Voided (same # and amount as canonical-side bills): 8692NCH-CDMX $2,860, 8788NCH-CDMX $1,984, 8777NCH-CDMX $406.41 — total $5,250.41 - Re-pointed to canonical (unique bills): 8986NCH-CDMX $248, 9010NCH-CDMX $152.93, 8988NCH-CDMX $2,350, 9056NCH-CDMX $617.44 Rationale: Baseline (2026-04-19) flagged the contact dup as a $13,869 "combined AP" split across two records. Deeper pull revealed 3 of the 7 dup-side bills were identical to canonical-side bills in InvoiceNumber and total, dated ~2 weeks later — i.e. whoever created the dup contact re-keyed the same 3 invoices in addition to adding 4 new ones. Real AP to Portilla is $8,618.78, not $13,869 — $5,250 was double-counted. Post-merge Portilla AP on canonical contact verified at $8,618.78. Alternatives considered: - (A) Re-point all 7 bills to canonical and leave the 3 pairs of same-# bills for manual cleanup later — rejected; consciously leaves $5,250 AP overstatement in place. - (C) Flag to JME / Austin for per-bill review — rejected per 2026-04-20 Austin confirmation; the 3 pairs match on both # and $, not a judgment call. Status: active. Executed via scripts/fpa/xero_merge_portilla.py --execute; 3 voids + 4 re-points + 1 contact archive, 0 failures. Voided bills remain on the archived dup contact per Xero default (void doesn't change contact pointer); this is fine — they show as VOIDED in the tax report regardless.

2026-04-20 — Sort Xero credit-card accounts: keep 2, archive 15

Decision: Of the 17 CREDITCARD-type accounts in the RFH Xero org, keep 2, archive 15 per Austin's classification rules. All 17 verified zero-bank-transaction before archive (safe; reversible). Keep: - 6009 Business Platinum Card®#001 — RFH's American Express business card - Brex Credit Card (BankAcctNo placeholder BREX) — aggregator account where the Brex connector posts all card activity, including the 2396 Mastercard Austin uses for RFH / Casa Moksha. Brex doesn't split per physical card by default. Archive (15): - 2009 Business Platinum Card® — belongs to RENFROE, the claims S-corp (out of scope for the RFH Xero org per critical fact #11) - 14 personal cards: Citi Strata Elite (0615), Citi/AA Executive (3764), Delta Platinum Business (2004), Delta SkyMiles Reserve (5006), G. Renfroe (7523), Hyatt Visa (3179), Marriott Bonvoy Bnd (9417), Marriott Bonvoy Brilliant (1000), Marriott Business (3762), Ritz Carlton (3194), Southwest RR Premier (2848), Private Bank Visa (0115), generic CREDIT CARD (1331), CREDIT CARD#001 (8587). Caveat (Austin's own words): "All of the others are personal, although I did put company expenses on them and I have the receipts saved in a folder (to earn points)." Those receipted business expenses need a separate reimbursement-from-personal workflow — they should not flow through these personal-card accounts in Xero. See accounting/personal-card-business-expenses.md for the proposed workflow. Cards Austin mentioned that are NOT currently in Xero: - 2396 Mastercard (Brex for RFH / Casa Moksha) — not a distinct account; activity comes through the Brex Credit Card aggregator. - 4790 Wise card (Casa Moksha / RHG) — Wise has no Xero connector; activity would need manual import or summary journal. Rationale: The default US BUSINESS Xero template seeded a generic CREDIT CARD account, then Brex's connector and various manual entries layered on more accounts than RFH actually owns. Personal cards in a business GL inflate the chart and create coding-mistake risk (someone reconciles a personal Marriott charge to a Marriott Business card by accident). Alternatives considered: - Leave personal cards active — rejected; encourages routing personal spend through the business books. - Delete instead of archive — rejected; archive is reversible, deletion isn't. Status: active. Executed via scripts/fpa/xero_cc_sort.py --execute 2026-04-20; 15 archived, 0 failures.

2026-04-20 — Backfill Entity + Asset Class tracking on the 19 AUTHORISED ACCPAY bills

Decision: Applied Entity + Asset Class tracking to all 19 AUTHORISED ACCPAY bills via rules-based assignment from contact name (and amount, for the Pearce split). Findings that reframed the task: - Baseline (2026-04-19) flagged "25 uncoded bills." Post-cleanup re-pull showed all 19 (post-Portilla void; pre-cleanup count was 22) bills DO have AccountCodes — Brex's connector default-codes them to 6330 Professional Fees. What was actually missing was tracking-category assignments. The categories themselves were created earlier today, so the options finally exist. - Pearce dollar split exactly matched accounting/vendor-mappings.md: $2,500 + $3,750 = $6,250 Five Points / Commercial Rental, $5,400 + $12,900 = $18,300 RFH / Holdings/Mgmt. High confidence on the entity allocation as a result. Confidence breakdown: - 16 bills coded DOC (rule directly supported by vendor-mappings.md): Portilla (7) → RHG/Hotel; Pearce (4) → split per amounts above; Alex Snider (5) → RFH/Holdings/Mgmt. - 3 bills coded GUESS (best-effort, flagged for Austin): ATP Fund II $30K, CONLEY ROSE $1,500, Desarrollo Anjona $37,700. See todo/for-austin.md for the questions. Rationale: Tracking is editable post-hoc, the assignment is reversible, and getting any reasonable assignment in place beats leaving 19 bills untracked while Austin investigates the 3 ambiguous ones. Alternatives considered: - Wait for full vendor-by-vendor confirmation from Austin/JME before any tracking applied — rejected; would block all entity-level reporting on these bills indefinitely while the question marks are on 3/19 only. - Apply only the 16 DOC bills, skip the 3 GUESS — rejected; partial coverage muddles "is this bill tracked or not" as a heuristic. Cleaner to track all 19 with explicit GUESS flags in the decision record. Status: active. Executed via scripts/fpa/xero_apply_bill_tracking.py --execute 2026-04-20; 19 ok, 0 failures.

2026-04-20 — FBAR threshold cross date and 2025 peak (Santander side)

Decision: Established that the Santander MXN account alone triggered Austin's FBAR filing obligation on Sep 24, 2025 (after the $300K MXN SPEI from JP Morgan took the balance to $329,122 MXN ≈ $18,143 USD). 2025 calendar-year maximum value for FBAR Form 114 Part II: $19,585.75 USD (Dec 15, 2025, after the "RNIE FINES AND CINDY PAYO" wire). 2026 YTD peak through Mar 31, 2026: $27,708.75 USD (Feb 12, 2026). Methodology: - Parsed all 293 transaction balance points from the 15-month Santander MXN history. - Reconstructed daily peak intraday balance (vs. end-of-day) so deposit-then-spend days don't get under-counted. - Converted to USD using FX rates interpolated from the 8 reconciled Brex→Santander wire pairs as anchors (USD/MXN traded 17.01 – 18.81 across the period). For 2025 dates before the first wire-based anchor, used 19.0 as a conservative proxy. For final filing, Pearce should re-verify with the Treasury YE official rate, but the threshold-cross date is robust to the methodology choice. What's still missing: Tokyo Star Bank (GK Japanese account) balance history. Awaits Mita Garden Hills closing docs. If TSB held escrow >$10K before YE 2024, 2024 also becomes a filing year. Rationale: Pearce flagged FBAR as item #5 in tax/2025-filing-prep.md but the timing and dollar amounts weren't quantified. Pearce can now proceed with the 2025 filing (deadline Oct 15, 2026 with auto-extension) without re-doing the spadework, and confirm whether 2024 was/should-have-been filed. Alternatives considered: - Use only month-end balances — rejected; misses the deposit-then-spend pattern that briefly takes the account well above the closing balance. - Use static FX rate (e.g., 19.0 throughout) — rejected; would systematically understate USD-equivalent in late 2025/early 2026 when the peso strengthened. Anchored interpolation gives a per-date rate within ±2% of actual market. Status: active. Full analysis in tax/fbar-analysis.md. Refresh procedure documented inline.

2026-04-20 — Renfroe Innovation established as a new tracked entity

Decision: Added Renfroe Innovation as a new Entity tracking option in Xero (TrackingOptionID be10589d-8694-4e17-a54e-a69e88b7972b) and re-tagged the $1,500 CONLEY ROSE bill (InvoiceID 20b10898-2f04-44a2-af16-ed3d070f1c6b) from Renfroe Family Holdings → Renfroe Innovation. Added a full section for the entity to context/entities.md. Rationale: Austin confirmed on 2026-04-20 that CONLEY ROSE (Houston IP/patent firm, $1,500, "Invoice No 726959") is for a new entity — Renfroe Innovation — that doesn't have a bank account yet and had not previously been documented. IP / innovation activity for the Renfroe ecosystem. Adding it to the Entity tracking dimension lets us capture future Renfroe Innovation expenses via tag (since there's no separate ledger) without conflating with Renfroe Family Holdings activity. Alternatives considered: - (A) Keep Renfroe Innovation expenses under RFH until the entity is formally stood up — rejected; conflates two distinct scopes and creates cleanup work when the entity is later formalized. Tagging today is cheaper than re-coding tomorrow. - (B) Leave Asset Class as Holdings/Mgmt vs. creating a new asset class — accepted for now; Renfroe Innovation is too early to warrant its own asset class. Revisit once the entity has defined activity. Status: active. Asset Class stays Holdings/Mgmt until Renfroe Innovation's scope is formalized. Open items for Austin: legal form, formation date, state, EIN, scope of activity — see todo/for-austin.md.

2026-04-20 — Personal LP / fund interests continue to be paid through RFH as distributions

Decision: The five LP / fund interests (ATP Fund II, Untapped Capital Fund II, Crosslink Capital, Garuda Ventures II, Overwater Ventures I) are held by Austin personally, not by Renfroe Family Holdings. Capital calls that RFH pays from Brex Primary on Austin's behalf book as owner distributions to Austin, who then pays the personal capital call. Austin offered to transfer the LP interests into RFH; decision postponed pending Pearce's input. Rationale: Austin confirmed the five interests are personal on 2026-04-20. Booking as a distribution (rather than an RFH expense) reflects economic substance and preserves the option to transfer the LPs later without basis / character complications from having pretended they were RFH assets in the interim. Transferring is a real tax-strategy decision — basis step-up vs. carryover, character of future gains, state tax exposure, LP-side approval / fees — and warrants Pearce's input rather than doing it now for convenience. Alternatives considered: - (A) Transfer LP interests into RFH immediately to eliminate the "RFH paying personal expenses" pattern — rejected without Pearce review; the veil-piercing tidiness benefit is real but tax mechanics may disagree. - (B) Require Austin to pay capital calls from personal funds (not RFH) going forward — acceptable but operationally harder; distribution treatment is strictly bookkeeping and doesn't require behavior change. Status: active. Five vendor entries in accounting/vendor-mappings.md reflect this (status known, Cap/Exp = EQ). Transfer-vs-hold decision on the Pearce question list.

2026-04-20 — $815K "Repayment of RENFROE Shareholder loans" books as RFH distribution to Austin

Decision: The $815,936 outflow from Brex Primary memo'd "Repayment of RENFROE Shareholder loans" (Austin Renfroe Personal) books on RFH as owner distribution to Austin. Austin then used those personal funds to repay RENFROE (the S-corp). RFH's books show only the distribution leg; the RENFROE-side receivable is on RENFROE's separate 1120-S books. Rationale: Austin confirmed on 2026-04-20 that RENFROE (the S-corp, out of scope for this Xero org per critical fact #11) loaned him the funds to help pay for Mita Garden Hills 1009, and he repaid RENFROE personally. The flow from RFH → Austin is a distribution; the flow from Austin → RENFROE happens outside the RFH Xero org. This keeps RFH books clean of RENFROE-side shareholder-loan tracking. Alternatives considered: - (A) Book as an intercompany loan from RFH back to RENFROE — rejected; RENFROE is a separate taxpayer and intercompany loans between RFH and RENFROE aren't the actual economic substance (the loan was RENFROE → Austin personal, not RENFROE → RFH). - (B) Route the $815K via Austin's personal account first, then out to RENFROE — would have been cleaner bookkeeping but isn't what happened operationally; the money moved directly from Brex Primary. Status: active. Pearce to confirm treatment on the RENFROE-side 1120-S (item on Pearce question list); vendor-mappings.md updated to status known.

2026-04-20 — Xero backup cadence: daily-capable JSON dump committed to repo

Decision: Xero backups are pulled via Custom Connection API into source-data/xero-backups/<YYYY-MM-DD>/ via scripts/fpa/xero_backup.py. Dumps include every readable list endpoint + the four key reports. Snapshots are committed to git (the repo IS the backup). Rationale: Self-hosted Gitea + full-history git gives versioned disaster recovery. Daily or weekly runs produce diffable snapshots showing ledger drift. No third-party backup service required; no secrets leave the trusted boundary. Alternatives considered: - (A) Third-party Xero backup service (Rewind, Backup My Xero) — monthly cost and adds another third party for sensitive data - (B) Cloud-only (Xero's own "restore" is cursor-based and limited) — inadequate - (C) Periodic manual CSV export — no automation, no history Status: active. First snapshot 2026-04-20: 113 accounts, 8 contacts, 25 invoices, 79 GL journals, 11 tax rates, reports TB/P&L/BS/BankSummary. 29 files committed.

2026-04-20 — Three advisory memos + four Casa Moksha integration steps drafted

Decision: Today's autonomous session produced, in order: 1. accounting/advisory-best-practices.md — 12 sections of ops/documentation risk grounded in transaction data 2. tax/advisory-tax-benefit-areas.md — categories A-F of under-emphasized tax opportunities (NOL-stacking, current deductions, state/local/international, structuring/timing, compliance, defer) 3. legal/advisory-contract-gaps.md — 24 contracts/resolutions that should exist + counsel attribution 4. accounting/chart-of-accounts.md — RHG-side Mexican COA draft appended (SAT Código Agrupador) 5. accounting/casa-moksha-intercompany-mockup.md — 18-month intercompany JE mockup, pressure-tested (substantially balances) 6. legal/intercompany-services-agreement-draft.md + legal/rfh-gk-treasury-framework-draft.md — framework drafts for counsel to edit 7. accounting/casa-moksha-capex-inventory.md — consolidated 2025 Q4 – 2026 Q1 capex by project (~334K MXN confirmed + ~116K pending JME, including the Anjona reorg estimate) 8. accounting/afr-loan-amortization-template.md + scripts/fpa/afr_amortization.py — AFR loan documentation template + generator script 9. accounting/vendor-mappings.md — extended with Feb-Mar 2026 Santander patterns (Rosa Maria bono, Alfredo ad-hoc, tramite juzgado, cedula catastral, generator items)

Rationale: Austin instructed (2026-04-20) to work autonomously through anything not blocked on his input or advisors'. This session did exactly that: every item above uses only data already in the repo. All are flagged DRAFT and explicitly call out the advisor/Austin confirmations needed before they become authoritative. Status: active. Each document carries its own status + next-steps; none have been posted to live Xero (per Casa Moksha integration plan's "NOT going to do until blockers clear" guidance).

2026-04-22 — Moksha Xero org decommissioned; rollup complete (skip-and-archive)

Decision: The separate "Moksha" Xero organization was decommissioned. Subscription canceled by Austin 2026-04-22. The 2026-04-19 single-org decision is now fully in effect: Renfroe Holdings is the only active Xero org. Rationale: Moksha was a pre-single-org bookkeeper-built testbed. Only 5 of 21 manual journals were POSTED (16 VOIDED); only 2 of 10 bank transactions AUTHORISED (8 DELETED) — i.e. the org's own history showed it was churn. Its 2023/2024 opening-balance journals will be superseded by the forthcoming JME Contadores monthly deliverable, so re-posting them into RFH would risk double-counting. Rollup scope actually executed (Phases 0-5): - Full Moksha snapshot captured → source-data/xero-backups/moksha-2026-04-21/ (disaster-recovery baseline, committed) - 26 Casa-Moksha-specific chart accounts folded into RFH (Investment-Furnishings, Spa Expenses, Hotel Occupancy Tax, Yoga Classes, Stripe Fees, etc. — full list in accounting/moksha-rollup-plan.md). RFH chart 113 → 139. - Santander supplier contact created in RFH (was missing entirely). - 5 POSTED manual journals intentionally NOT migrated. Flagged for post-JME-deliverable review in todo/for-austin.md (see "Revisit Moksha's 5 POSTED manual journals after JME deliverable arrives"). - Contacts, tax rates, tracking categories, invoices, bills: nothing worth migrating. Alternatives considered: - (A) migrate-the-5-posted — port the 5 POSTED journals to RFH. Rejected: JME's numbers will supersede them. - (B) full-copy — clone entire Moksha chart + contacts + journals. Rejected: most would be duplicates and Moksha is a pre-decision testbed. Status: active. Supersedes accounting/moksha-rollup-plan.md Phases 0-5 (all now complete). The ~/.config/renfroe-fpa/xero-moksha.env credentials and local token cache were removed 2026-04-22 after subscription cancellation. Note: Xero retains a 7-year archive of canceled orgs, readable but not writable.

2026-05-08 — M365 multi-tenant connectivity established (Renfroe Holdings + Casa Moksha tenants)

Decision: Stand up read-only Microsoft Graph access from this LXC into both Austin's M365 tenants via a single multi-tenant Azure AD app registration. Tooling lives in scripts/inboxes/m365.py; per-tenant refresh tokens in Vaultwarden under renfroe-holdings/m365-{cm,rfh}-token. Rationale: Active legal (Portilla / Cindy consignation), tax (Pearce CPA), and operational (JME, Tokyo Star Bank, Pinnacle, Withers) email + file context lives in M365 and was previously inaccessible. With connectivity in place, the FP&A workflow can mine concrete dates, decisions, and counterparty status directly rather than relying on Austin to summarize. Scope of access: delegated read scopes only (Mail.Read, Calendars.Read[.Shared], Files.Read.All, Sites.Read.All, Chat.Read, ChannelMessage.Read.All, Team.ReadBasic.All). The Azure AD app is consented for read+write, but m365.py enforces read-only at the token-scope level. Future write-enable is a one-line script change + re-auth. Alternatives considered: - (A) claude.ai Microsoft 365 MCP connector — only authenticates one tenant at a time; would require swapping connections to switch tenants. - (B) Sharepoint-only via Synology /volume1/cloud replica — covers SharePoint but misses live mail, calendar, Teams chats, and is point-in-time-stale. - (C) per-tenant separate app registrations — more Azure plumbing for no functional gain over multi-tenant. Status: active. Smoke-tested 2026-05-08 across mail / calendars / events / files / sites / chats / teams in both tenants; all surfaces returned real data.

2026-05-08 — Five Points / 1006 / Woolworth SBA story corrected (Loan 7803 is on Woolworth, not 1006; Hunter is borrower)

Decision (informational, not a treatment change): the prior framing in entities.md, decisions/log.md (2026-04-19 SBA decision), accounting/vendor-mappings.md, and accounting/afr-loan-amortization-template.md attributed the active SBA EIDL collection to "defunct 1006 LLC" with Austin as the obligor. After mining the RFH-tenant mail (Sep–Oct 2025 thread with Stuart Memory at Memory Memory & Causby), the corrected facts are: - The active EIDL is Loan #4300957803 ("loan 7803") on The Woolworth LLC, not 1006 20th St S LLC. - Hunter Renfroe (Austin's brother) is the original borrower; Austin is a personal guarantor (confirmed Sep 26 2025 by Stuart Memory). - A separate $150K SBA loan on 1006 20th St S LLC exists but Austin is NOT a personal guarantor on it (confirmed Oct 2 2025). - Two more loans visible in Austin's SBA portal: a larger ~$1.2M loan (entity TBD) and a fourth charged-off loan (details unknown). - The $7,965.60/mo Brex outflow continues to flow on the original schedule (no payment-plan deal yet); collection was reactivated Sep 13 2025 after a charge-off period. Why this matters: the booking treatment from 2026-04-19 (Five Points → Austin distribution → Austin personal payment of guaranteed debt) remains correct — what's wrong is the entity attribution in supporting docs. The treatment doesn't depend on which entity holds the SBA debt because Austin pays via PG either way. Why also material: dissolution of the Woolworth + 1006 shells was evaluated and rejected in Sep 2025 (Chuck Murphy / Stuart Memory analysis): dissolving them would crystallize the SBA debt onto guarantors immediately. Brex 0926 (1006 defunct, zero balance) must NOT be closed, contrary to the earlier note in banking/brex.md / Brex transaction analysis. Annual filings (registered agent, annual reports) for both shells must be maintained. Status: active. Entries in entities.md and accounting/vendor-mappings.md updated 2026-05-08. Full chronology in accounting/five-points-1006-sba-narrative.md.

2026-05-08 — Chuck Murphy + Waterloo Capital take over RFH family-office operations (Aug 2025 onward)

Decision (informational, captured from RFH mail mining): as of Aug 17, 2025, Chuck Murphy ([email protected]) replaced Laurence Reeves as Austin's RFH family-office operations lead. Chuck operates from Waterloo Capital, LP (Austin TX) and partnered with Michelle Kultgen (Managing Director, Waterloo Capital Family Office Services, [email protected]) starting Sep 8, 2025. Together they took over operational coordination of: 1006/Five Points (with Edgewood + TRC), Casa Moksha + Oceana (with Alex Snider), Mita Garden Hills (with Saho/Shu), and SBA collection (alongside Stuart Memory). Operational footprint as of late Nov 2025 includes: - Edgewood billing switched from auto-ACH draws to invoice-based (Oct 24 2025) — affects future Brex EDGEWOOD PARTNER cadence - 1006 building 2026 property tax bill cut in half via Walter Scott Law protest (Nov 2025) engaged through Skinner Legal - 1006/Woolworth dissolution evaluated and rejected (Sep 25 2025) - Pearce Bevill delivered Woolworth financials in person (Oct 27–28 2025) - Five Points BHM Notice of Forfeiture of Right to Transact Business filed by Alabama SoS Nov 12 2025; cure status TBD - Active LOI / leasing for 1006 building underway with TRC (Bill Clements, Brooks) — Five Points moving from "pre-revenue" to operating commercial rental once tenant signs Status: superseded by 2026-05-09 entry "Chuck Murphy correction — friend (not brother), no longer running RFH FO." The Aug 2025 → late-2025 operational record above remains historically accurate for that role-window; what the 2026-05-09 supersession changes is (a) the relationship framing and (b) Chuck's current status. People entries in context/people.md updated 2026-05-08 (rewritten 2026-05-09 to reflect Austin's correction). Full activity log in accounting/five-points-1006-sba-narrative.md.

2026-05-08 — Mita Garden Hills 1009 purchase price reconciled — JPY-anchored at ¥835,355,900 paid to seller side

Decision: Set the canonical Mita Garden Hills 1009 acquisition cost in this repo at ¥835,355,900 total economic cost paid to seller side, expressed in JPY (not USD). The buildup is ¥760,000,000 original 2023-04-25 sales contract (¥544.92M land + ¥195.53M building ex-tax + ¥19.55M consumption tax) + ¥53,905,500 Special Changes Addendum (signed 2024-08-15: ¥41.8M Just Fit Select bespoke modifications + ¥11.9M Option Select upgrades + ¥0.165M consult fee, all incl. 10% consumption tax) + ¥21,360,200 closing fees at delivery (registration, property-tax equivalent, repair-fund contributions per Mitsui's Financial Plan) + ¥90,200 stamp duty net buyer cost. Plus ¥4,130,000 estimated real estate acquisition tax to local Tokyo authority (separate, post-delivery, not in seller wires). Tracing: Two RFH wires to Mitsui Fudosan in 2025 = ¥835,259,800 total (¥152,080,000 settled 2025-04-04 from Brex Treasury USD$1,029,284.76 + ¥683,179,800 settled 2025-04-24 from Pinnacle bridge). Δ to implied total = ¥5,900 (rounding-level noise from closing-fee variance). Austin's original ¥152,000,000 personal deposit (paid April 2023) was refunded to him at WF 6248 as ¥151,909,800 (net of ¥90,200 stamp), per the 2025-03-31 Overseas Remittance Refund Request Form and the 2025-04-04 Ownership Change Agreement Article 3 — refund timing post-closing, exact deposit-out date pending WF 6248 statement. Rationale: All advisor-facing numbers must reconcile to primary documents. Pre-2026-05-08, the repo flagged the Mita purchase price as TBD because Austin had said the Special Changes Addendum pushed the actual paid amount above the ¥760M contract figure. With the Synology share mounted on proxmox and the Closing Documents folder mined end-to-end, the addendum total (¥53,905,500), wire confirmations (¥152.08M + ¥683.18M = ¥835.26M), Pinnacle bridge ($3.5M term loan to Austin signed 2025-04-21, matures 2025-06-21), TSB mortgage (¥780M base advanced 2025-07-28 at FX 148.89), and ownership-change refund (¥151,909,800) are all primary-document-anchored. JPY rather than USD is canonical because USD-equivalent shifts depending on FX-date convention (closing day vs. weighted average across wires) and that allocation belongs to Shu Endo + Pearce. Implementation: Full reconciliation memo: accounting/mita-purchase-price-reconciliation.md. context/entities.md § Mita acquisition story updated with the headline numbers, full 15-step funding-path timeline, and complete Synology document index. todo/for-austin.md Mita reconciliation items marked closed; new follow-ups added (WF 6248 statements May–Sept 2025, April 8 2025 GK-as-buyer contract from Mitsui Realty, Pinnacle bridge maturity ↔ TSB takeout 37-day gap). todo/for-advisors.md Japanese accountant section updated with Shu/Kyomi Endo names and the basis-allocation question pre-loaded. Alternatives considered: - (A) Quote the ¥760M original contract price as the "purchase price" — rejected; ignores the ¥53.9M of capital improvements that are part of GK's basis, would systematically understate depreciation. - (B) Quote a USD-equivalent number — deferred; depends on FX-date convention which is an advisor decision (Shu Endo for JP-side basis, Pearce for US-side translation). - (C) Wait for the Japanese accountant to provide closing statement — rejected as the gating constraint; we have all the source documents (contracts, addenda, wires, refund paperwork, Pinnacle bridge note, TSB outgoing wire calc) in the Synology share. Shu Endo is needed for the basis allocation, not the cost reconciliation. Open items (not blocking the canonical figure): - WF 6248 May–Sept 2025 statements to confirm refund deposit date + USD-equivalent - April 8 2025 GK-as-buyer sales contract (currently only the dissolution agreement is in the share) - Pinnacle bridge actual payoff date and amount (bridge matured 2025-06-21, TSB disbursed 2025-07-28 — 37-day gap likely covered by extension) - TSB mortgage promissory note + amortization schedule (have the disbursement calc, not the loan agreement) - Real estate acquisition tax payment status (¥4,130,000 estimated) - Land-vs-building-vs-furnishings allocation (proposed split in the reconciliation memo for Shu Endo to confirm) Status: active. JPY figures locked. USD-equivalent and final allocation pending Shu Endo + Pearce.

2026-05-08 — Cindy Canto removal mechanism = Mexican payment consignation proceeding

Decision (informational, captured from CM mail): RHG is removing Cindy Canto via the Mexican Civil-Code "payment consignation" (consignación de pago) procedure required by RHG's bylaws — formally tendering MXN $500 (her capital fijo) into court so the obligation is legally satisfied irrespective of her cooperation. Rationale: Mandatory under RHG bylaws and Mexican law before her share can be retired. Three terminal outcomes: (a) she appears + accepts, (b) she no-shows, © she appears + refuses; in (b) and © the obligation is still deemed satisfied per the Court. Path © reserves her right to pursue separate litigation but does not block the cap-table cleanup. Status: in-flight. Service-of-process is the active blocker. Letter rogatory issued from Quintana Roo court → Yucatán courts (her only known address per her CSF tax certificate). Service attempted 2026-04-23 at "Calle 49F #393, Fracc. Francisco de Montejo, Mérida" — failed because the actual subdivision is "Francisco de Montejo II" (typo in her CSF). Portilla preparing motion for re-attempt at corrected address; Alex Snider executing 3 originals; René to file at Yucatán court. See legal/cindy-consignation-timeline.md for the full timeline. Alternatives considered: - (A) negotiated settlement with Cindy — she escalated 2026-03-28 with hostile demands ("final opportunity to pay me"), refused offered terms; not a viable path. - (B) skip consignation, rely on alleged-fraud removal grounds alone — bylaws require formal payment consignation regardless of grounds; skipping = bylaws non-compliance. Status: active.

2026-05-08 — Renfroe Innovation, LLC scope reconciled — real entity since 2010, real IP, not "new"

Decision (informational, captures the Topic 6 mining pass): Renfroe Innovation is not a "new entity, scope TBD." It is a Texas LLC as of 2025-12-05 (TX file # 806342204), converted from an AL LLC (2017-07-10) which itself was converted from Renfroe Innovation, Inc. (AL C-corp formed 2010-04-05). EIN 27-2287462 since 2010-04-07, carried across both conversions. Sole owner: Austin personally (since 2014-04-01 when Hunter assigned his shares). It holds 3 issued US patents (US 10,445,672 / 10,445,819 / 11,900,288) in the "Bar Management Software" family (Conley Rose matter # 4447), with one application (4447-00106 / S/N 18/407,110) in active prosecution as of 2026-04-26 (§101 OA, response/interview pending). Active counsel: Conley Rose (Michael Piper, IP), Kim & Rosado (Tony Kim, entity/tax — also filed BOIR 2024-11-13 via Peter Chang), Pearce Bevill (Robert Cook, accounting/tax). RI is owned by Austin personally, not by RFH. Rationale: The repo's prior framing in entities.md ("Form: Not yet documented (legal form, EIN, state TBD)" and "First documented activity: $1,500 CONLEY ROSE legal bill 2026-04-20") was wrong on every dimension. Rebuilding from the Synology document share, the M365 RFH-tenant mailbox, and the Gmail archive surfaces 50+ Conley Rose patent invoices going back to 2013-05 plus full formation/conversion paperwork. The $1,500 Xero bill that prompted the Apr 2026 tracking-option creation is one invoice in a 13-year billing relationship. Alternatives considered: - Treat the Apr 2026 entry as accurate and leave the entity as "scope TBD" — rejected; the underlying records contradict that framing and any 5471 / 1120 / disregarded analysis hinges on getting the entity right. - Make RI a subsidiary of RFH retroactively — rejected for now; the IP-assignment + tax-classification implications need Pearce + Kim & Rosado sign-off before any cap-table change. Status: active. Entry replaced in context/entities.md. Full scoping in context/renfroe-innovation-scope.md. Three open items remain — federal tax classification (disregarded SMLLC vs. residual C-corp from 2010 vs. S-corp), trademark "RENFROE INNOVATION" registration status (filed 2012 via Balch & Bingham, never followed up here), and Xero historical-cost backfill of pre-2026 IP spend.

2026-05-09 — Portilla billing entity allocation: 100% RHG, intercompany-cleared if paid from RFH cash

Decision (informational, captured from full debit-note mining): Every Portilla, Ruy-Díaz & Aguilar bill in the 2024-11 → 2026-04 universe (32 debit notes, $59,561.75 invoiced) is RHG-attributable legal work — RHG SA → S. de R.L. de C.V. conversion (CORPORATE), Cindy consignación, or LABORAL. None is RFH-only general-corporate. The "paid from both sides" pattern flagged in accounting/vendor-mappings.md was operational, not legal: through 2025-11, payments came from Brex Casa Moksha Ops 3753 (correct RHG cash); from 2025-12 onward, the wires shifted to Brex Primary 8798 (RFH cash). All Primary-paid Portilla wires (~$11,601.78 lifetime) need reclassification through the RFH→RHG intercompany account per the 2026-04-19 settlements decision. Rationale: Live mining of every NC PDF (extracted via scripts/inboxes/portilla_pull.py + portilla_parse.py) confirmed matter references 1:1 across all 32 bills; cross-checked against Brex transaction history (Primary + CM Ops, full 2024-2026 windows) and live Xero state (/Invoices?where=Contact.ContactID==Guid("4e028e3c-...")). Drift surfaced: Xero currently has only 7 Portilla bills (all AUTHORISED, $8,618.78 AP). 22 in-window bills are entirely missing from Xero ($25,693.30 of legal activity invisible to the GL); $8,001.34 of Xero AP is for bills that have actually been paid via Mar 11 + Mar 23 wire batches; NC 8478 ($1,798) was wired from Primary 4 times Feb 2026 with all attempts canceled, still genuinely unpaid. Live outstanding AP per the reconciliation: $22,420.34 across 10 bills. Full schedule: accounting/portilla-billing-reconciliation.md. Status: active. Xero AP cleanup tracked in todo/tech-automation.md § "Xero baseline cleanup". Statement-of-account ask to Mary Infante and the 8 unpaid in-window bills tracked in todo/for-austin.md § Portilla.

2026-05-09 — Casa Moksha guest-revenue gaps mostly closed via SP (Moksha) retreat contracts + RFH Brex deposit alerts

Decision (informational, captured from Topic 8 mining pass): Identified or refined identity for 6 of the 7 outstanding Casa Moksha Dep guest-side counterparties using the retreat contracts at /SP (Moksha)/Guest Relations/Retreat Documents/, the master Moksha Reservation Calendar_Shared.xlsx, and the [email protected] → [email protected] deposit-alert stream in the RFH M365 tenant. - CLOSED: Richard Rosenblum (5-night Rentals Tulum buyout Jan 4–9 2025, $24,360 exact); Inner Warrior Retreats / Kerry Tice (6-night direct buyout Feb 9–15 2025, $15,528 contract; partial $10,126 wire — reconciliation gap surfaced); Uri Metsarme Lia Pavlia Shvili → Nino Togonidze "Tata" (6-night direct buyout Apr 9–15 2026, $13,500 exact). - WORKING HYPOTHESIS (M-H): CO DASH LLC ($42,293.60 across 4 wires Dec 24 2024 / Jan 6 / Jan 14 2025) is the payment vehicle for Brian Begin "Hypnotic Visions" retreat (Jan 12–21 2025) booked via Coworking Tulum. $9,929 excess over the $32,364 contract is consistent with chef/meal/extension add-ons; the $3,780 outflow Jan 29 2025 fits a partial refund/settlement. Austin to confirm. - STILL UNKNOWN: Secluded Serenity LLC ($689.50, Jan 23 2025) — no contract, no email, no calendar booking. Jose Pablo Gonzalez Deleze / NVIO ($20K MXN, Jan 14 2026) — no email or contract evidence. - DEFAULT TREATMENT: Ariella S Laden ($300 inflow Mar 17 2025 followed by outgoing transfer to Ariella Laden Mar 24 2025) is being treated as a cancelled booking refunded within the window — reverse and exclude from realized revenue unless Austin says otherwise.

Rationale: With external-data connectors live (M365 multi-tenant + Synology NFS), the FP&A workflow can resolve guest-side counterparty identification directly from booking artifacts rather than relying on Austin to summarize. The Synology mirror of CM SharePoint surfaced the retreat-contracts library in /SP (Moksha)/Guest Relations/, which is the system-of-record for direct bookings post-Cindy and pairs cleanly with the Brex deposit-alert stream.

Status: active. Full ledger in accounting/casa-moksha-guest-revenue-ledger.md; counterparty table in context/people.md updated; open items moved to todo/for-austin.md + open-questions.md (Q14, Q15, Q17, Q17b–d).

2026-05-09 — Casa Moksha wire-level reconciliation via Brex API closes Q14, Q17, Q17d

Decision (informational, captured from Topic 8 follow-up via direct Brex API): Pulled the full Casa Moksha: Dep (3529) + Casa Moksha: Ops (3753) transaction history via scripts/fpa/brex_client.py, exposing per-wire memos that were not visible in the Brex deposit-alert HTML or the prior CSV summary. This collapsed the remaining ambiguity on three previously-open guest-counterparty questions: - CO DASH LLC = Brian Begin's "Hypnotic Visions" retreat (Jan 12–21 2025) via Coworking Tulum. Wire decomposition matches the contract exactly ($9,709.20 = 30% deposit + $22,654.80 = 70% remainder + $8,885.60 + $1,044.00 post-arrival add-ons = $42,293.60). Casa Moksha paid Olas Tulum $3,265.65 (Suite @ Las Olas pass-through bundled into Brian's package) + $3,780 back to CO DASH ("payment for invoice" agent commission). Net realized: $35,247.95 before chef/meal COGS. - Secluded Serenity, LLC = booking-affiliate / agent. Memos: "COMMISSION FOR PEI JAN 2025" + "JAN 2025 RESERVATION COMMISSION". "PEI" = Peiman Fazil = Brian Begin contract contact. Treat as agent / channel revenue, not direct guest revenue. - Ariella S Laden = small individual stay Mar 20–24 2025 with 50% refund. Memo: "ARIELLA LADEN 3/20-3/24". $300 deposit → $150 refunded Mar 24 → $150 retained as cancellation fee. Recognize $150 in March 2025; do NOT reverse the full inflow.

Bonus surfaced: new named guest Jim Kocjancic (3-person small reservation Dec 27–30 2024, $500/night × 3 = $1,500) from the memo on the 2024-12-31 Gavon Renfroe inflow.

Rationale: The Brex deposit-alert email HTML strips down to styled formatting that doesn't surface the wire memo cleanly; the Brex transaction CSV snapshot in source-data/brex/2026-04-19-full-history-analysis.md aggregates by counterparty without preserving per-wire memos. The live Brex API (/v2/transactions/cash/{account_id}) returns a description field with the full wire memo from the originating bank's MT103/ACH detail line, which is the authoritative source.

Status: active. Q14, Q17, Q17d closed in open-questions.md. Q17b (Inner Warrior $3,582–$5,402 gap) still open — pending PayPal-side data. Q17c (Anita Vita) still open. Q15 (NVIO / Jose Pablo Gonzalez Deleze) still open. Wire-level inflow ledger captured in accounting/casa-moksha-guest-revenue-ledger.md.

2026-05-09 — SUPERSEDES 2026-05-08 Chuck/Waterloo entry — Chuck Murphy is Austin's friend (not brother) and is no longer running RFH FO

Decision (correction from Austin, direct): Chuck Murphy is Austin's friend, not his brother. Chuck is no longer running Renfroe Family Holdings family-office operations as of this confirmation. The 2026-05-08 decisions-log entry above (and the inferred-from-mail framing it captured) is superseded by this entry on both points.

What stays accurate from the prior entry: - The Aug 17, 2025 handoff from Laurence Reeves to Chuck Murphy is a documented historical event (per RFH-tenant mail). - Chuck operated from Waterloo Capital, LP and partnered with Michelle Kultgen (Sept 8, 2025 onward) during his role-window. - All operational events tied to that period (Edgewood billing-cadence change Oct 24; 1006 property-tax protest Nov; 1006/Woolworth dissolution analysis Sept 25; Five Points BHM Alabama SoS Notice of Forfeiture Nov 12; in-person Pearce delivery Oct 27–28) remain accurate as historical record.

What is now corrected: - Relationship: friend, not brother. Earlier framings ("Austin's brother" in accounting/five-points-1006-sba-narrative.md, "brother (per RFH-tenant mail context — verify with Austin)" in context/people.md, "TBD-confirmation" in context/people-graph.md Finding 24) all updated. - Current status: Chuck is inactive as RFH operations lead as of 2026-05-09. The end-date of his Aug 2025 → 2026 tenure is TBD with Austin (not specified at correction time). The current RFH operations-lead identity (if anyone has stepped into that role) is also TBD with Austin.

Files updated this session: context/people.md, context/people-graph.md, context/inconsistencies-audit.md (Finding 24 closed), context/document-audit-2026-05-09.md, context/entities/renfroe-family-holdings.md, context/entities/five-points-bhm.md, context/master-timeline.md, accounting/five-points-1006-sba-narrative.md, tax/pearce-bevill-thread-summary.md.

Status: active. Supersedes 2026-05-08 Chuck/Waterloo entry on relationship + current-status framing only; the historical operational record from that prior entry is preserved.

2026-05-09 — Cindy Canto separation framing corrected — quit before fired; no payout; illegal acts are the substantive removal grounds

Decision (correction from Austin, direct): Three corrections, layered on top of the 2026-05-08 "Cindy Canto removal mechanism" entry:

  1. Cindy quit before she was fired. Repo language framing her exit as a "termination" / "separation Austin initiated" was wrong. She resigned ahead of pending termination.
  2. No separation payout was issued to Cindy. Repo language asserting a "Cindy severance" / "Cindy separation payout" — derived from inferring the Dec 15, 2025 JPMorgan wire memo "RNIE FINES AND CINDY PAYO" as a severance line — was wrong. The wire's "PAYO" component does not refer to a Cindy payout. The RNIE-fines portion of the same wire IS real (JME-confirmed 2025-12-11 — RNIE = Registro Nacional de Inversiones Extranjeras, the Mexican Foreign Investment Registry, which has real fines for late filings). What the "PAYO" component refers to is unresolved and queued for Austin/JME clarification.
  3. The substantive grounds for removing Cindy from the corporation are her illegal acts, not a clean operational separation:
  4. Threats against Austin and employees
  5. Illegal transfers of retreat-booking funds to her personal account during her tenure as hotel manager
  6. Embezzlement more broadly

The Mexican payment-consignation proceeding (legal/cindy-consignation-timeline.md) is the procedural mechanism required by RHG bylaws to retire her capital fijo; the substantive grounds are the illegal acts above. The bookkeeping disarray during her tenure (which JME's 2025 back-tax catch-up cleaned up) is downstream of the underlying fraud, not a separate operational complaint.

What stays accurate from the prior 2026-05-08 entry: - The mechanics of the consignación de pago, the three terminal outcomes per Diego Alcantara (appears+accepts / no-show / appears+refuses), and the in-flight service-of-process timeline at the Yucatán court are all unchanged. - Cindy's hostile 2026-03-28 emails ("final opportunity to pay me") remain in scope as part of the broader pattern. - Cap-table mechanics (1% / MXN $500 capital fijo, fraudulently added without authorization, 46.7M MXN capital variable 100% Austin per JME) unchanged.

Files updated this session: context/people.md, legal/cindy-consignation-timeline.md (new "Why she's being removed" section), accounting/vendor-mappings.md, accounting/chart-of-accounts.md (lines 422 + 560), accounting/advisory-best-practices.md, accounting/casa-moksha-intercompany-mockup.md (Sample C rewritten + reconciliation list updated), accounting/jme-deliverable-status.md, banking/santander-mxn.md, todo/for-austin.md (Cindy + RNIE-FINES-wire entries), todo/jme-questions-2026-04-29.md (severance question removed, wire-purpose question kept open), todo/remaining-work-summary.md, open-questions.md (Q21 rewritten), context/document-audit-2026-05-09.md, source-data/jme/2026-04-29/README.md.

Status: active. Supersedes the relevant inferences from the 2026-05-08 entry without contradicting its core framing of consignación as the procedural removal mechanism.

Pending (not yet decided)

  • Whether to close Santander USD account ($950 pending penalties) vs. fund to $1K
  • Intercompany services agreement structure: no-fee vs. arm's-length service fee
  • Check-the-box election for Renfroe Hospitality Group (pending Pearce's answer on current status)
  • Check-the-box election for Renfroe Holdings GK (pending Pearce's answer)
  • PFIC approach for GK if rental doesn't qualify as trade-or-business (QEF vs. MTM vs. default)
  • Forecasting tool — Fathom vs. Spotlight vs. Float (deferred until Tier 1 live)
  • Bank feed mechanism for Santander MXN into Xero (manual CSV vs. third-party feed)