# Finance Workflow Change – Host Resolution Payments Handling ## Summary The Finance team is introducing a structural change in how **Host Resolution Payments** are recorded and processed in our systems. This affects the **source of truth** for these transactions and requires a coordinated update across our **Data Warehouse (DWH)** and **reporting models**. --- ## What’s Changing? ### **Previous Approach:** - Host resolution payments were handled as **bank transactions**. - Stored in the `xero.bank_transactions` table. - Payments categorized using: - `account_code = 323` → *E-Deposit Resolution - Host Payment* - `account_code = 316` → *Resolutions - Host Payment* ### **New Approach:** - Host resolution payments will now be handled as **credit notes** instead. - Stored in the `xero.credit_notes` table. - Categorization remains the same: - `account_code = '323'` → *E-Deposit claims* - `account_code = '324'` → Check In Hero - Resolutions (Guest) (new as of 23.04 7pm) - `account_code = '316'` → *All other resolution payments* --- ## Effective Date > 🔔 This change applies to all resolution claims made on or after > > > **📆 March 31st, 2025** > --- ## Implementation Plan ### Step 1: Create Unified Resolution Payments Table A new table will be introduced in the DWH that consolidates **host resolution payments** from both: - `bank_transactions` (for transactions **before** March 31st, 2025), and - `credit_notes` (for transactions **from** March 31st, 2025 **onward**). This ensures continuity in analysis and reporting across the transition. --- ### Step 2: Review & Update Downstream Models We will **review all DWH models that depend on**: - `xero.credit_notes` - `xero.bank_transactions` …and assess how the change might affect: - joins - any possible aggregations that might be affected [Credit Notes Downstream Analysis](Credit%20Notes%20Downstream%20Analysis%201de0446ff9c980d9a0c1fd9477d7fcb7.md) --- ### Step 3: Update Reporting The following reports are expected to require updates: - **Main KPIs Report** - **Host Resolutions Report** More may follow depending on dependencies. --- ## Key Considerations - Ensure **no double counting** during the transition period (e.g. if one payment is mistakenly captured in both sources). - Validate that the new credit notes data includes **all fields** currently used in `bank_transactions`. - Coordinate QA testing with Finance to verify totals match.