All Meetings

## Summary The meeting focused on resolving technical and configuration tasks related to a SOC 2 compliance audit and addressing specific feedback for a UBM demo account. Key discussions centered on preparing the demo environment with appropriate data and settings for an upcoming demonstration, while ensuring ongoing compliance work proceeds without disruption to other customers. ### SOC 2 Compliance Progress Updates on two parallel tracks of the SOC 2 compliance effort were reviewed. - **Vendor Management**: The review and documentation of all third-party vendors used by the company is largely complete, with only a few remaining items needing final verification. - **GCP and Avanta Integration**: The task to integrate Google Cloud Platform (GCP) with Avanta has been assigned, and initial work has begun. It was suggested to create a dedicated internal Slack channel for faster, more focused discussions on such compliance and technical tasks among the core team. ### UBM Demo Account Configuration and Feedback A significant portion of the meeting was dedicated to addressing feedback from a user (likely a customer success or sales representative) regarding the UBM demo account. The goal is to optimize the account for effective product demonstrations. - **Cleaning Up Superfluous Data**: It was confirmed that custom location attributes currently visible in the demo account are unnecessary and can be removed to present a cleaner interface. - **Data Population and Analytics Default View**: A primary concern was that the main analytics report initially loads with sparse or outdated data, which is not ideal for demos. A script is being prepared to generate and import more recent data (for 2024 and 2025) from other customers into the demo account. This population of contemporary data is expected to resolve the issue of empty default views, making a default filter change to 36 months unnecessary. - **Handling Data Validations**: There was a request to re-enable bill validation errors in the demo to showcase the platform's error-checking capabilities. However, a technical limitation was noted: simply re-parsing existing bills will not resurrect old, resolved errors. The proposed solution is twofold: first, re-enable the validation system, and second, ensure the newly imported data contains bills with unresolved errors. The demo team was advised to preserve a set of known "error" bills without editing them to consistently have validation examples to show. - **Customizing Default Report Views**: Feedback indicated that the default expanded "tree view" in a report was cluttered for demo purposes. A significant technical constraint was identified: the main analytics report and its default filters are shared globally across all customers. Therefore, any change to the default view (like collapsing the tree) would impact every client, which is not acceptable. A future solution discussed involves duplicating the main analytics report to create a demo-specific version that can have custom default filters without affecting other users, but this is not currently implemented. ### Data Validation and Error Display A detailed technical discussion clarified the mechanics of showing validation errors within the demo environment. - **Re-enabling vs. Re-processing**: The distinction was made between reactivating the validation system and the act of re-parsing existing bills. Turning validations back on will flag new errors in incoming data. - **Limitation with Existing Data**: For bills where errors were previously identified and marked as "resolved," re-parsing them will not make those specific errors reappear, as the system remembers their resolved state. This means simply reprocessing old data will not restore the validation display that the demo team found useful. - **Strategy for Demos**: The effective strategy is to ensure the demo account contains a fresh set of data (via the new import) with inherent, unresolved validation errors. This will provide authentic examples of the platform's validation features during demonstrations.

## Summary The meeting focused on reviewing the current development status of several key features within a credential and billing validation system, with particular attention to bug fixes, new functionality, and data synchronization processes. ### Credential Validation System Updates A critical bug fix was deployed to the production environment to correct the logic for matching credentials. Previously, the system could incorrectly match records based only on customer, vendor, and password, bypassing the essential account number check. The fix now ensures all matching is done correctly using the combination of customer, vendor, and account number, which resolves issues with "mismatching password" and "mismatching username" flags. - **Fix for Mismatched Account Number Logic**: The matching algorithm was updated to enforce validation against the account number, a crucial field for accurate credential pairing. - **Removal of Redundant Filter**: An additional task was identified to remove the "mismatching account number" filter from the user interface's "needs action" list, as this state is not actionable for users in the current workflow. ### Archive and Comments Functionality Development is underway for an archive feature, which is intended as a soft-delete mechanism for invalid credentials. This functionality is seen as a necessary stepgap before implementing a full bi-directional sync with external systems. The related ability to add comments to credentials was also discussed to help teams log reasons for actions taken during their review process. - **Archive as a Soft Delete**: The archive feature will allow users to mark credentials as invalid without permanently deleting them, creating an audit trail and preparing data for future cleanup tasks in other systems. - **Comments for Auditability**: While comments can be added, their primary use is expected to be within the validation interface itself, rather than on a separate management page, to provide immediate context during the review workflow. ### Failed IPS Records Investigation An investigation was conducted into a specific error state where bill records show a status of "failed IPS complete." In this state, the pre-audit JSON data becomes empty, preventing users from taking corrective action. The root cause was traced to a specific step in the data processing pipeline. - **Root Cause Identified**: The issue occurs after the IPS extraction completes but a subsequent processing step (ND JSON DTO) fails. A bug was found where the system uses a `save` operation instead of an `update`, which inadvertently clears the pre-audit JSON data. - **Proposed Solution and Impact**: A code fix has been prepared to correct this logic. Once reviewed and deployed, it will prevent the issue for future records. For the 17 existing production records stuck in this state, the fix may allow them to be re-processed correctly. ### User Interface Enhancements for Validation Work is in progress to add new filtering capabilities to the bill validation screen, improving the team's ability to locate and manage specific records efficiently. - **New Filter Criteria**: Development is ongoing to add dropdown filters for **Client ID**, **Vendor**, and **Bill ID**. This will significantly enhance the searchability of records compared to the current interface. - **Implementation Standard**: The new filters are required to follow the same dropdown format already established in other parts of the application, ensuring a consistent user experience. ### Account Synchronization and File Uploads Significant progress was reported on the automatic sync of account data from an external platform (Arcadia) and the subsequent upload of statement documents to SharePoint. Initial testing revealed important data discrepancies that require resolution. - **SharePoint Upload Structure**: The automated process successfully creates a structured folder hierarchy in SharePoint: a main folder for the Client ID, subfolders by date, and individual statement files named with client, account, and statement details. Future improvements will include adding the client name and statement date to the file/folder names for better readability. - **Data Discrepancy Analysis**: During testing, a major discrepancy was found between the number of account credentials stored internally (~2600) and the number successfully synced from Arcadia (~1700 for credentials, ~1200 for accounts). This highlights a potential gap in data integrity. - **Strategic Approach to Validation**: The team emphasized the importance of thoroughly validating the sync logic and understanding these discrepancies for the first client before scaling the process. This careful approach is crucial to prevent compounding errors for future clients. A technical adjustment was also made to process records in smaller batches to avoid system timeouts during the sync operation.

## Summary ### Transition from Direct Messages to Structured Channels The core announcement involves a strategic shift in internal communication, moving away from relying on direct messages (DMs) for project and operational discussions towards utilizing dedicated Teams channels. This migration will begin with the "DS product ops" channel and is expected to expand to other communication flows in use. The primary motivation is to improve the clarity, organization, and traceability of team discussions. ### Key Benefits of Using Dedicated Channels Adopting proper channels is presented as a solution to several limitations inherent in DM-based communication. The central advantage is enabling more coherent and referenceable conversations. - **Improved Discussion Threading:** Channels facilitate organized threads around specific topics, which prevents the common issue of fragmented replies and makes it easier to follow the entire context of a conversation without losing reference to the original point. - **Enhanced Tool Integration:** Structured channels offer better compatibility and integration potential with other software tools used by the team, paving the way for a more connected and automated workflow in the future. ### Practical Tips for Managing Teams and Channels To ease the transition and help team members manage the new structure effectively, several practical tips for using Microsoft Teams were shared. These focus on personal organization and reducing visual clutter. - **Customizable Sections for Organization:** Users can create custom sections within their Teams interface (e.g., "Favorites," "Later") to categorize and prioritize channels and chats, allowing for a personalized workspace that suits individual workflows. - **Flexible Channel Visibility:** The interface allows users to hide or show channels as needed. This is particularly useful for managing a large number of channels, as users can selectively display only the most relevant ones and collapse sections to maintain a clean and focused view. - **Dynamic Member Management:** Channels support the flexible addition of members as required, ensuring the right people have access to relevant discussions as initiatives evolve. ### Implementation and Forward Path The change will be implemented gradually, starting with the migration of specific discussions from DMs to the "DS product ops" channel, with a plan to extend this model to other areas. The announcement concludes with an open invitation for feedback on the new communication approach.

## Summary The meeting consisted of a single, brief announcement regarding a significant upcoming change in the team's communication tools. ### Announcement of Communication Platform Migration A major transition from Microsoft Teams to a new, unspecified platform was announced. The core announcement was the decision to move away from Microsoft Teams as the primary communication tool. The announcement was delivered with a sense of deliberate action, though the specific replacement platform was not named during this initial communication. This change signifies a strategic shift in how the team will collaborate and communicate moving forward. ### Rationale for the Change The underlying reasons and expected benefits for this migration were not detailed in this initial briefing. While the "what" was clearly stated-moving from Teams-the "why" behind this decision was not elaborated upon. This leaves the strategic drivers, such as seeking improved functionality, better integration with other workflows, cost considerations, or enhanced user experience, as topics for future discussion or follow-up communications. ### Transition Timeline and Process No specific timeline or detailed migration plan was provided during this announcement. The announcement served as a preliminary heads-up rather than a detailed rollout plan. Key logistical details, including the projected start date, the phased migration approach, data transfer procedures, and the final cut-over date from the old to the new system, remain to be communicated. ### Implications for Team Workflow The change will inevitably impact daily operations, though the exact nature of the impact is still undefined. Moving to a new communication platform will affect various aspects of team workflow. This includes routine activities like instant messaging, video conferencing, file sharing, and project channel management. The announcement implicitly signals a future period of adaptation and learning as the team familiarizes itself with the new tool's features and interface. ### Next Steps and Future Communication The announcement concluded without outlining immediate action items or a clear channel for questions. This initial message appears to be the first step in a longer change management process. The lack of detailed next steps suggests that follow-up communications will be required to address team questions, provide training resources, and establish a concrete project plan for the migration itself.

## Summary The provided transcript is extremely limited and does not contain substantive discussion from which a meaningful meeting summary can be generated. The single line of dialogue present appears to be an opening greeting or small talk, which, according to the provided instructions, should be excluded from the summary. ### Insufficient Content for Detailed Summary **The transcript does not contain discussable meeting topics or decisions.** The available content is a fragment that does not allow for the identification of key themes, action items, or conclusions as required by the summary template. - **Transcript Length and Depth:** The transcript consists of only one short speaker turn, which is insufficient to reconstruct the context, purpose, or outcomes of any meeting. - **Absence of Discussed Topics:** No project updates, strategic discussions, problem-solving, data analysis, or planning conversations are present in the provided text. Therefore, no level-2 or level-3 headings for specific topics can be created. - **Implication for Summary Fidelity:** Generating a detailed, fluent, and engaging summary that follows the prescribed template is not possible without the actual content of the meeting dialogue. The summary would be entirely speculative and not based on the evidentiary transcript.

## Summary The meeting primarily focused on optimizing the demo environment for the UBM platform to enhance sales effectiveness, addressing several technical and data-related issues that impact demonstration quality. A significant portion was also dedicated to discussing pricing strategy and feature development, particularly around handling customer data in Excel format. ### Demo Environment Optimization This discussion centered on making the demo account more polished and effective for sales presentations by removing non-essential elements and ensuring data displays correctly. - **Removing Non-Core Features:** To streamline demos and focus on core UBM value propositions, it was agreed to hide the SAM module and the Sustainability tab from the demo environment by default. The Sustainability tab, in particular, can create confusion during sales pitches for the core platform and often raises more questions than it answers regarding data update frequency and methodology. It can be revealed selectively if a prospect expresses a specific interest in emissions tracking. - **Fixing Data Validation Displays:** A key issue was identified where bill-level error validations (e.g., alerts for consumption spikes) were not displaying, showing only generic system information instead. This removes a useful storytelling element from demos. The action is to re-enable these validations specifically for the demo account and re-process historical bills to restore this functionality. - **Cleaning Up Location Attributes:** The demo account's location attributes contain numerous legacy fields (e.g., EE Measure 1, ECM2) that clutter the interface and are irrelevant for demonstrations. These will be removed to present a cleaner, more focused view to prospects. ### Platform Performance and User Experience Challenges related to system speed and default settings within the platform were reviewed, as they directly affect demo fluidity and first impressions. - **Addressing Slow Load Times:** Acknowledged performance issues, particularly when loading the portfolio view, were attributed to current server architecture and traffic patterns. A migration to a new Azure infrastructure scheduled for August/September is expected to resolve these through optimized load balancing. - **Adjusting Default Report Views:** Multiple reports (e.g., Bill Health, Anomalies, Light Bills) were found to default to date ranges with no data (e.g., 2025, 2026), presenting blank or unhelpful views. Solutions under consideration include updating the demo account with more recent mock data or changing the default date settings (e.g., to "last 36 months") specifically for the demo environment to ensure useful data is displayed immediately. - **Refining Filter Defaults:** In the analytics section, filters are pre-populated upon login, requiring manual clearing to start a clean analysis. The plan is to adjust these global defaults to start with a blank slate, improving the demo flow. ### Data Reporting and Integrity The conversation highlighted the need for accurate and presentable data within reports to effectively demonstrate the platform's analytical capabilities. - **Ensuring Report Data is Current:** For reports to be compelling, they need to reflect recent time periods. The team is evaluating methods to populate the demo account with data that appears current, such as backdating existing data, to make analytics and health reports immediately valuable during a demo. - **Clarifying Excel Data Ingestion:** A major strategic topic was how to handle prospects who require ingestion of utility data from Excel files instead of PDF bills. The consensus is to develop a standardized, robust process with clear rules of engagement, including a strict required format, SFTP setup, defined error-handling responsibilities, and an associated per-meter fee. This aims to move away from one-off custom solutions. ### Sales Strategy and Product Development The discussion expanded into broader sales enablement and product roadmap topics to strengthen the overall sales pitch and address common prospect inquiries. - **Identifying Key Differentiators:** To bolster the sales pitch, core platform strengths were identified, particularly its user-friendly interface that allows for intuitive drilling from high-level portfolio views down to granular bill details without overwhelming the user-a contrast to competitors that may present overly complex data dumps. - **Developing a Shareable Roadmap:** There is a recognized need for a sanitized, high-level product roadmap that the sales team can reference with prospects. The goal is to create a monthly visual update highlighting major upcoming features (like interval data integration) in customer-friendly language, without exposing internal operational tickets. - **Pricing Model Evolution:** The discussion emphasized the need to formalize pricing for non-standard services like Excel ingestion to ensure profitability and account for ongoing support costs. The approach will involve creating a standard offering with clear associated costs, moving away from highly customized, and potentially loss-leading, agreements.

## Summary ### Overview of the Credentials Validation Screen A walkthrough was provided for the Production DSS application, specifically focusing on its credentials validation functionality. The primary purpose is to manage and clean up credential discrepancies between different data sources. - **Application Access and Purpose:** The demonstration was conducted within the Production DSS app, which houses the total inventory of credentials. The immediate focus is on the cleanup process for specific sets of credentials, such as those for Vectra. ### Core Function: The "Needs Action" Filter The central tool for the cleanup task is the "Needs Action" filter. Activating this filter isolates credentials that require attention by excluding any that are already consistent and valid. - **Filtering Logic:** Clicking "Needs Action" and then "Search" will display only credentials falling into four specific discrepancy categories: those with mismatching usernames, mismatching passwords, accounts existing in only one source (either Data Services or UBM), and mismatched clean accounts. - **Critical Filter Behavior:** It is crucial to understand that adding multiple filters works on an **AND** logic, not an OR logic. Applying additional filters concurrently will narrow results further and likely return zero records, so it is recommended to use only the "Needs Action" filter initially for the broadest view of issues. ### Types of Credential Discrepancies The filter reveals several common scenarios that need resolution, each requiring a specific action based on the nature of the discrepancy. - **Account in a Single Source:** A credential may exist in only one system, such as Data Services (DS) but not in UBM. In this case, the available action is to set the present system (e.g., DS) as the source of truth. - **Mismatched Details Between Sources:** More frequently, an account exists in both systems but with slight variations in details, such as username spelling. These require manual review to determine the correct information and set the appropriate source of truth. - **Handling Invalid Credentials:** For credentials that are invalid, archived, or deleted, a future archiving functionality is planned. For the current process, such records can be noted and potentially ignored for the time being. ### Process for Resolving Discrepancies The interface provides a methodical workflow for investigating and resolving each flagged credential. - **Review and Action:** For each credential listed, users can view associated information like the URL and account number. The key step is to click "Resolve Discrepancy," which opens the interface to address the specific issue. - **Setting Source of Truth:** The resolution process involves designating which system-Data Services or UBM-holds the correct, authoritative data for that credential. - **Adding Context:** Users have the ability to add notes to a credential, providing context or rationale for the resolution decision, which aids in auditability and future reference. ### Current Limitations and Future Updates The tool is operational for core cleanup tasks but is acknowledged to be a work in progress with enhancements on the way. - **Immediate Workflow:** The current guidance is to rely on the "Needs Action" filter as the primary tool for identifying credentials requiring cleanup. - **Planned Enhancements:** Development is ongoing, with updates promised for the future. Specifically mentioned is the forthcoming ability to archive invalid or deleted credentials directly within the system, which is not yet available in the production environment. - **Interface Notes:** During the demo, minor interface interactions were noted, such as controls for Zoom and Teams, confirming the application is designed for detailed inspection and collaborative review.

## Summary ### Pricing Strategy and Historical Context The meeting opened with a discussion about the company's current and historical approach to pricing and customer billing. Historically, pricing was not standardized, often requiring direct contact to sell, with the primary goal being a 20% margin. Currently, the average margin achieved is around 35%, which is considered acceptable but not ideal for a SaaS business model. Broker fees were clarified as an ongoing customer acquisition cost, not a one-time marketing expense, where a dollar per meter is paid to brokers for the lifetime of the customers they bring in. - **Lack of bottom-up cost analysis:** A significant historical gap was identified: no one has ever calculated the fundamental cost per service, per bill, or amortized development spend. This absence of granular cost data has made precise pricing and margin optimization difficult. - **Pricing as a reaction, not a strategy:** The initial pricing model was described as lacking foresight, established simply to secure sales rather than as part of a strategic, product-led growth plan. ### Operational Challenges with Data Ingestion A core operational bottleneck centers on how customers submit invoice data, specifically the handling of Excel files. Many customers request the ability to submit formatted Excel files via SFTP, but the company has historically refused, leading to lost deals and reputational damage as being unresponsive to customer needs. - **High cost of manual processing:** The existing, semi-manual process for handling non-standard Excel files is performed by the data services team. While previously tolerable at high volumes due to lower fixed costs, the opportunity cost is now higher as this team could be focused on more valuable work like data cleanup or UBM operations. - **The need for a scalable solution:** The discussion strongly advocated for moving away from custom, one-off solutions for individual customers. Instead, any new capability for Excel ingestion should be built as a robust, standardized feature that can be offered to multiple customers, thereby turning a historical pain point into a scalable service. - **Shifting cost responsibility:** To improve margins, there was consensus on the need to charge customers explicitly for any special handling or support required for data ingestion, such as a per-meter or per-bill fee, rather than absorbing these operational costs. ### Product Development Priorities and Technical Debt The conversation highlighted critical product features that have been long-requested but unimplemented, creating significant operational overhead. The amount of manual work performed pre- and post-processing on the platform is not reflected in the pricing, which is a key reason margins are not at typical SaaS levels. - **The SFTP upload/download solution:** The most direct solution to many data ingestion issues would be a native feature within UBM for customers to upload bills and download payment files themselves. This feature has been on the roadmap for years, with past demos existing, but it was never fully implemented due to ancillary issues like file naming conventions and system design hurdles. - **Breaking the cycle of operational debt:** A vicious cycle was identified: the development team cannot build new features because they are too busy handling operational issues, and they are busy with operations because sales has sold custom, non-standard solutions. Breaking this chain is imperative for product progress. - **Empowering the customer:** The philosophy emerged that the platform should push more responsibility onto the customer for simple, repetitive tasks (e.g., drag-and-drop uploads, verifying data), allowing the company to focus its paid efforts on processing and platform intelligence. ### Customer Feedback, Reputation, and Strategic Alignment The company's repeated "no" to common customer requests like Excel ingestion has been damaging, creating a perception that the development team does not listen to customer feedback. Upcoming projects require careful internal communication to manage expectations and incorporate control-focused feedback. - **Recapturing lost opportunity:** It was noted that there are likely at least ten customers from the past year who were declined and could now be re-engaged if a standardized Excel ingestion feature were available, representing a direct opportunity to recoup lost revenue. - **Pre-launch stakeholder reviews:** For upcoming features like the new credentials view, it is considered critical to get pre-emptive, friendly reviews from key internal stakeholders (like Tara in Sales Ops) to anticipate pushback and align messaging before broader communication. - **Incorporating finance and controls perspective:** The involvement of finance personnel (like Jeff Lochte) focused on controls and risk management is crucial, especially for projects like Arcadia which are seen as a panacea. Their concerns and questions must be addressed early in the planning process to ensure solutions are sound and compliant. ### Planning for Sales Enablement The final part of the discussion focused on an immediate need to update the demo account data to better showcase the platform's capabilities for sales demonstrations. This task highlights the disconnect between sales needs and development bandwidth. - **Creating representative demo data:** The goal is to generate a clean, ideal dataset that showcases key features (services, bills, fees, errors, locations, analytics) with a controlled, minimal error rate (e.g., 99% clean, 1% error) to demonstrate error-catching capabilities without overloading the demo system. - **Understanding the sales perspective:** The preparation work involves thinking from a sales persona viewpoint: mapping out the customer's starting point, desired ending point, and the specific features that bridge that gap. - **Addressing historical delays:** This data update request has been outstanding with another team for nearly a year without action, underscoring the persistent resource tension between ongoing operations and strategic enablement work.

## **Summary of January Unplanned Work and February Planning** This meeting served as a brief check-in to address pending items from January and to review the roadmap for upcoming projects in February. The discussion focused on quantifying unplanned work, resolving external dependencies for report generation, and assessing the timeline and scope of key development initiatives. Offers for managerial escalation to unblock external partners were also extended. ## **Unplanned Work Review for January** A primary objective was to close out the accounting for unplanned engineering work completed in January. This involves categorizing and quantifying tasks that fell outside the planned sprint cycles. - **Request for Unplanned Work Data**: There was a specific request to compile a list of all unplanned work items and reports generated during January. This data is crucial for tracking team bandwidth and understanding interruptions to the planned roadmap. The expectation is that the volume of unplanned fixes was significant, similar to previous months. - **Action on Data Compilation**: The data will be sourced directly from the project management tool (Jira) to ensure accuracy. The compilation will include not just a list of tasks but also the calculated percentage of time spent on unplanned work versus planned work, providing a clear metric for the month's productivity distribution. ## **Updates on Pending Reports and External Dependencies** Progress on several reports, which depend on data from an external payment provider (PayClarity), was reviewed. The conversation centered on identifying blockers and determining if managerial intervention was needed. - **General Progress with PayClarity**: For most reports, such as those concerning *electronic payment conversions* and *SLA monitoring*, alignment on timing is proceeding without major issues. The external partner is providing the necessary data, suggesting a functional working relationship for these items. - **Specific Data Field Blocker**: One report is currently blocked because a required data field is not available from PayClarity's standard systems. A solution is being investigated on their end, and it was noted that direct follow-ups are already in progress, making further escalation seem unnecessary at this time. - **Offer for Managerial Escalation**: A standing offer for facilitation and escalation was made, following a discussion with higher management who inquired about project blockers. This offer is particularly relevant for more complex future requests that may require the external partner to undertake custom development work not aligned with their other clients' needs. - **Timeline Expectations for Pending Items**: For the reports without specific blockers, completion is anticipated to be a matter of internal review and timing coordination. The goal is to finalize and account for these reports within the January period. ## **Project Outlook for February and Beyond** The roadmap for February was briefly examined, with acknowledgment that some projects may face delays or require scope adjustment. - **Arcadia Integration Timeline**: The integration project with Arcadia is expected to spill over into March. However, a significant milestone, termed "phase 1.5," is still targeted for completion within February. This indicates a phased delivery approach is being adopted. - **Credential Management Project**: Work on the credential management system is confirmed to be on track for progress in February. - **Potential Scope Reduction**: The "interpreter layer" project is under consideration for being pushed back or potentially scrapped altogether, as a need for it may no longer exist. This reflects adaptive planning based on evolving project requirements. - **Multi-Factor Authentication (MFA) Work**: The status of MFA-related tasks is uncertain for February. Meaningful progress is not expected unless some aspects can be absorbed into the ongoing Arcadia integration work, necessitating a separate, internal discussion to determine the path forward. - **Holistic Account Health Project**: This was mentioned as a substantial undertaking, implicitly acknowledging it as a significant piece of work on the horizon without diving into detailed planning during this check-in.

## Credentials Management and Filter Fixes The meeting focused on critical updates to the credentials management system. A primary issue with the "Needs Action" filter was successfully resolved, and the fix is ready for deployment to the production environment. - **Fix for the "Needs Action" Filter:** The logic for this filter was corrected to properly display all records that require attention. The filter is designed to flag any credential mismatches, such as missing credentials in one system or discrepancies in usernames and passwords, which is crucial for the team to identify and resolve issues. The corrected version has been tested and is currently deployed on the development server. - **Priority for Production Deployment:** Due to the operational need to begin credential remediation work immediately, pushing this specific fix to production was prioritized above other tasks. All other recent changes related to credential presentation were confirmed to be working correctly in production. - **Clarification on Filter Logic:** There was a discussion about whether multiple dropdown filters should use an "AND" or "OR" logic when combined. It was clarified that the current implementation uses an "AND" logic, but for the team's workflow, the correct functioning of the standalone "Needs Action" filter is the most important requirement. ## Archiving Functionality for Invalid Accounts A new feature was developed to handle accounts that are no longer valid or active within the system. - **New Archiving Capability:** A button was added to the comparison module, allowing users to manually archive specific account records. This helps in cleaning up the active view by removing outdated entries. - **Viewing Archived Records:** A corresponding dropdown filter was also implemented, enabling users to view the records that have been archived. This functionality provides a complete audit trail and prevents permanent data loss. This new archiving feature has been deployed to the development environment for testing. ## Performance and Deployment Strategy The conversation included important notes on system performance and a cautious approach to rolling out changes. - **Acknowledgment of Performance Lag:** It was noted that the credentials interface can be slow to load, likely due to the volume of records being processed. While acceptable for now, optimization was identified as a future consideration to improve the user experience. - **Rigorous Testing Protocol:** A new, more cautious deployment strategy was emphasized. The team agreed that for any significant new features or changes, they must be thoroughly held and tested in a staging environment first. Feedback from operators or other end-users should be gathered before any production release to prevent disruptions to daily work. ## UI and Data Format Corrections Several user interface and data formatting bugs were addressed and fixed. - **Calendar Date Field Display:** An issue where date fields in the calendar UI were not displaying correctly when empty was resolved. The fix ensures the interface properly shows empty fields and consistently passes dates in the correct format to the backend API. - **Pagination Listener Fix:** On the status page, a bug was fixed where the updated page number was not being listened to after a user change. This ensures smooth navigation when paging through data. Both of these fixes have been pushed to the production environment. ## Account Synchronization with Arcadia Significant progress was made on syncing internal account data with the external Arcadia system, which is key for automating statement retrieval. - **New Account Sync Feature:** A new synchronization function was created that, when provided with a client ID, fetches all corresponding account information from Arcadia, including the Arcadia account ID for each internal account. This sync must be manually triggered. - **Purpose of the Sync:** The primary goal is to establish a reliable link (mapping) between internal account numbers and Arcadia's unique account IDs. This stored mapping will allow for more efficient API calls to download statements, eliminating the need for multiple lookups. - **Future Automation Potential:** The discussion explored the possibility of automating this sync in the future. One proposed method is to update the account ID mapping automatically every time a response is received from Arcadia's API, which would keep the data continuously accurate. The value of also pulling metadata like "next expected post date" and "latest statement" from Arcadia was noted for future consideration. ## SharePoint Integration for Statement Management Work continued on integrating SharePoint to automate the storage and retrieval of client statements. - **Current Development Focus:** The immediate task is to complete the programmatic integration with SharePoint to facilitate the downloading of statements from Arcadia and their subsequent upload to the correct SharePoint locations. - **Planned Implementation Scope:** Initially, the plan is to start by downloading statements on a monthly basis, targeting the month of February as a starting point. - **Client-Specific Organization:** A key requirement is that the downloaded statements must be split and organized by customer or client within SharePoint. The newly established Arcadia account ID sync will be instrumental in achieving this, as it ensures each statement can be accurately associated with the correct internal client account.

## Overview of DSS App Date Handling Issues The meeting centered on addressing two critical problems related to date input and storage within the DSS application. The primary focus was on rectifying data integrity issues and improving the user experience by ensuring consistent and correct date field interactions. ## Core Date Storage Issue The application is currently storing user-entered dates incorrectly in the database, which poses a significant risk to data integrity and report accuracy. - **Incorrect date storage:** There is a mismatch between how dates are entered by users and how they are ultimately saved to the database. This discrepancy could lead to incorrect data in reports and analytics, undermining the reliability of the entire system. - **Clarification of expected behavior:** A reference screenshot was provided that outlines the correct, expected format and method for storing dates. The immediate technical priority is to audit the current storage logic and align it with this defined standard to prevent further data corruption. ## Inconsistent Date Input Methods A key usability flaw was identified where the application fails to provide a date picker for all fields that are technically designated as date fields, forcing manual text entry. - **Missing date pickers for date fields:** Several fields that are defined as date types within the application's schema do not trigger the dedicated date picker UI component when selected. This forces users to type dates manually, which is error-prone and leads to inconsistent data formats. - **Proposed solution for consistency:** The requirement is to intelligently detect when a user clicks into any cell that corresponds to a date-type field and automatically present the standard date picker component. This would standardize input, reduce errors, and improve the overall user experience. ## Technical Implementation Priorities The discussion framed the work as two distinct but related technical tasks that need to be addressed to resolve the overarching date handling problems. - **Investigation of storage logic:** The first task involves a deep dive into the backend or data layer code to identify why dates are being transformed or saved incorrectly between the user interface and the database. - **Enhancement of UI field detection:** The second task focuses on the frontend, requiring an update to the logic that renders input fields. The system must be modified to reliably identify all date-type fields and invoke the appropriate picker widget, eliminating the need for manual entry. ## Next Steps The immediate action item following the meeting is to commence a thorough investigation into both outlined issues, starting with the data storage discrepancy. The resolution of these problems is considered urgent to maintain data quality and application usability.

## **Summary** The meeting focused on providing critical feedback and feature requests for improving a credentials management and test environment system. The discussion centered on current functional limitations, interface clarity, and deployment priorities to enable immediate operational use. ### **Issues with the Current "Needs Action" Filter** The primary filtering mechanism intended to isolate accounts requiring attention is not functioning as expected, leading to an overwhelming and inefficient review process. - **Inaccurate Results:** Applying the "needs action" filter still displays a large number of accounts, suggesting the filter is not correctly isolating items with genuine discrepancies. This undermines the tool's core purpose of streamlining credential reviews. - **Conflicting Filter Logic:** Attempting to use multiple specific filters simultaneously (e.g., mismatching usernames, mismatching passwords) creates confusion. It is unclear if these filters are designed to be used in conjunction or independently, hindering precise searches. ### **Ambiguity in Discrepancy Resolution** The system is flagging accounts for resolution where no clear difference is visible to the user, reducing trust in the automated validation. - **Unclear Discrepancy Indicators:** Specific accounts are marked for resolution despite appearing identical in both username and password fields (e.g., `energy123` vs. `energy123!`). The root cause of the flag-potentially a difference in the associated URL or another hidden field-is not surfaced to the user, making resolution impossible without guesswork. ### **Suggested Interface and Workflow Improvements** Proposals were made to reorganize the interface for better focus and future functionality. - **Dedicated Validation Tab:** It was suggested to split the credentials management into a separate "credentials validation" tab. This dedicated space would provide a clear, running count of items needing action, giving teams an immediate high-level view of their workload. - **Future Account Management Feature:** A longer-term need was identified for the ability to archive or soft-delete accounts. This would be crucial for handling accounts that are found to be invalid or closed, providing a way to clean the system without permanent deletion, especially for accounts that only exist in one environment. ### **Critical Deployment and Production Issues** Urgent attention was demanded for system stability and making the new features available to end-users. - **Production Deployment Failure:** The credentials management page in the production environment is currently non-functional. Ensuring a stable deployment to production is the highest priority. - **Immediate Operational Need:** Even if all proposed improvements are not complete, the core validation functionality must be live in production to allow teams to begin reviewing client credentials the following day. The improvements made and documented (noted as "the copy is already in") must be pushed to the production environment without delay.

## Current Task Status The immediate technical task of adding a credentials status column to an existing database table is nearly complete, requiring only a few more minutes of work. This sets the stage for the next phase of development. ## Automated Bill Retrieval and Storage System A new automated process needs to be built to pull the latest billing documents ("builds") from the Arcadia system on a daily basis. The core objective is to eliminate the manual step of logging into individual vendor portals. - **Establishing a Central Repository:** The files will no longer be stored locally but in a shared location. Options discussed include an FTP folder or a newly created SharePoint site, with the latter being readily available. - **Storage and Organization Logic:** The system must store files on a monthly basis. A highly desirable feature is to organize these files by customer, which would significantly streamline subsequent manual processing for the operations team. - **Execution Scope:** This automated retrieval and storage process is intended to be a persistent solution, continuing until a fully automated ingestion pipeline is built, acting as a critical interim efficiency improvement. ## File Naming and Organization Strategy A consistent naming convention for the retrieved bill files is essential for clarity and manual handling. The convention will incorporate key data points from Arcadia. - **Naming Convention Components:** File names should include the vendor name, account number, and a relevant date field. - **Date Field Hierarchy:** A clear priority for the date field was established: the **statement date** is the primary choice. If unavailable, the **due date** should be used. As a final fallback, the **service period end date** can be utilized. - **Folder Structure:** An organization scheme for the SharePoint was suggested, involving creating monthly folders (e.g., "February") and potentially sub-folders for each client within them for optimal order. ## DSS Application Enhancements Concurrent with the automated retrieval system, modifications are required in the DSS application's upload interface to accommodate the new workflow. - **Expanding Queue Options:** The upload function's dropdown menu needs additional queue selections. The incoming bills are all destined for the prepay queue, and adding this option explicitly will prevent misrouting to priority or on-demand queues. - **Task Management:** Behind the scenes, logic must ensure that tasks generated from these uploads are appropriately snoozed according to their new queue assignment. ## Client-Specific Data Handling A significant part of the discussion centered on whether and how to associate retrieved bills with specific clients automatically, which would add substantial value. - **Automated Client Identification:** The ideal workflow would automatically group bills by client without requiring a manual selection interface. The feasibility hinges on whether the new credentials status table (or another source) contains the necessary data to map an Arcadia account to a specific client. - **Value of the Feature:** Successfully implementing per-client organization would make the file repository intuitive for the operations team to navigate and would improve tracking and accountability for each client's documents. ## Queue Management Considerations There was a clarifying discussion on how the different queue types within the DSS application function, which informs the needed enhancements. - **Existing Queue Mechanics:** Currently, selecting "batch" uses an OpenAI batch queue with a 24-hour turnaround, while "on demand" uses an API for instant response. The prepay, postpaid, and backlog queues all internally utilize the OpenAI batch process. - **Handling Live Bill Volume:** A key consideration for future phases is managing the potentially high volume of uploaded "live" bills. The system must leverage the existing, robust queuing mechanisms appropriately to ensure stable processing, though specific implementation details are deferred until later in the project. ## Next Steps and Collaboration The plan forward involves parallel work streams and clear communication to maintain momentum. - **Task Documentation and Assignment:** The discussed requirements and naming conventions will be formalized within an updated EPIC (project tracking document), which will then be shared to guide development. - **Immediate Action:** Development of the automated bill retrieval service is the immediate next priority. - **Resource Coordination:** There is bandwidth available from another team member (Tina). Progress updates or requests for assistance can be communicated directly via the development team channel at the end of the day for efficient collaboration.

## Summary The meeting centered on the urgent implementation of the Arcadia platform to solve critical bottlenecks in the invoice download and processing pipeline. The primary goal is to drastically reduce the time between an invoice being published online and its download, which currently averages 8 days, severely eating into standard payment cycles. Arcadia is seen as the necessary external solution to automate this process. The discussion outlined a phased implementation plan, immediate interim manual processes, and several technical hurdles that need to be resolved for a full, automated deployment. ### The Core Problem and Arcadia's Role The central issue is an unsustainable 8-day average delay in downloading invoices after publication, which consumes half of a typical 15-20 day payment window. This delay is the primary driver for implementing Arcadia, an external tool designed for automated, timely invoice retrieval. The initiative is critical for all bill-pay customers, as timely download is the first and most crucial step in the end-to-end payment process. ### Phase 1: Credential Cleanup and Initial Setup The immediate first step is to ensure all customer credentials for utility portals are accurate and up-to-date in both the internal system (UBM) and Arcadia. A cooperative student (co-op) has been assigned to clean the credential list, with an aim to close a roughly 10% gap in accuracy. The cleaned credentials will enable Arcadia to begin downloading invoices. The initial focus will be on a subset of customers for testing before a broader rollout. ### Phased Implementation Timeline A multi-phase rollout was proposed. The interim manual process begins immediately. The target is to have **all bill-pay customers onboarded to Arcadia for web downloads by mid-February**, with the remaining non-bill-pay customers added by the end of February. This timeline is contingent on successful credential cleanup and resolution of technical dependencies. ### Interim Manual Process and Folder Structure Until full automation is achieved, a manual interim process will be used. Downloaded invoices from Arcadia will be placed in a shared directory with a specific folder structure: - **Customer-specific folders:** Each client (e.g., "Constellation") will have a dedicated main folder. - **Date-based subfolders:** Within each customer folder, subfolders will be created based on the invoice date (e.g., "2025-01"). A cascading logic for determining this date was agreed upon: using the statement date first, then the due date, and finally the service period end date. - **Manual review & upload:** A designated person from the data services team will review the invoices in these folders, confirm the client, vendor, and account number, and then manually drag-and-drop the PDFs into the DSS (Data Services System) for processing. A "loaded" subfolder will be used to track processed invoices. ### Key Technical Hurdles and Automation Dependencies For long-term, scalable success, two major technical milestones must be achieved to move beyond the manual bottleneck: 1. **Building a managed pipeline and directory:** Creating an automated system to receive and track files from Arcadia, providing full visibility and control over the flow of invoice data. 2. **Injecting metadata into the process:** Developing a service to log critical metadata (client ID, vendor ID, account number) at the time of the API call to Arcadia. This will allow for automatic matching and identification of invoices upon download, eliminating the need for manual review. Options include using Arcadia's custom fields or unique IDs. ### Reporting and Success Metrics Establishing reporting capabilities from Arcadia data is essential for monitoring the initiative's success. Key metrics identified include: - The total number of invoices requested for download versus the number successfully retrieved. - Tracking which January (or current month) invoices have been pulled and identifying what is missing. - Overall coverage to understand how much of the total invoice volume (approximately 20,000 for bill-pay customers) is being handled by Arcadia versus requiring manual intervention.

## Customer The customer is Constellation Energy, who operates in a dual capacity: both as a **vendor** providing energy supply and as a **client** using the platform for their own energy management and bill processing. They have a complex account structure involving thousands of service accounts and require integration for historical and ongoing bill retrieval. ## Success The most significant success demonstrated involves the effective use of the Arcadia integration for automated bill retrieval. For energy vendors *other than Constellation*, the process is working smoothly. Bills are successfully pulled in bulk through Arcadia's API, automatically organized into customer-specific folders, and delivered via a shared drive or FTP. This automation has effectively replaced a highly manual, bill-by-bill download process, proving the value of the platform's data aggregation capabilities for streamlining operations. ## Challenge The primary and most pressing challenge is the **inability to automatically download a backlog of approximately 3,300 historical invoices directly from Constellation Energy's own portal**. Attempts to use automated scripts or crawlers are being blocked by Constellation's network security. Furthermore, there is confusion and a lack of established process regarding account credential management. The team lacks the necessary centralized credentials (like a master login for the Constellation portal) to authorize tools like Arcadia to access these bills on behalf of the Constellation client entity. This is compounded by data alignment issues, as some accounts on the list may be "rate ready" and not have actual invoices available, leading to potential mismatches and wasted effort. ## Goals The customer's immediate and longer-term goals center on resolving the invoice backlog and establishing reliable, scalable processes: - To obtain the backlog of roughly 3,300 Constellation bills in the next 24-48 hours, evaluating options like Arcadia bulk pull, a dedicated file container, or a manual download as a last resort. - To establish a clear, documented, and responsible workflow for adding new Constellation customer accounts to the central credential portal (CEP) to prevent this issue for future bills. - To implement a sustainable, automated method for ongoing Constellation bill retrieval, preferably through an integration like Arcadia that can deliver files directly to a designated FTP location. - To clarify the scope of the backlog by reconciling the list of requested bills with actual enrolled accounts to avoid processing non-existent or out-of-scope invoices.

## **Summary** The meeting focused on several key operational and technical initiatives to streamline workflows and enhance data accessibility. Topics included coordinating support for a new team member, implementing a temporary storage solution for billing documents, managing firewall access for a data visualization tool, and improving error handling within an existing service. The discussions were solution-oriented, with clear next steps identified for each item. ### **Coordination for Credentials Sync Support** A new team member, Kanish, will require assistance with credentials synchronization processes. He will initiate contact directly, and all necessary support will be coordinated to address his questions, including scheduling calls across time zones. - **Direct support channel:** Kanish has been instructed to contact the relevant person directly via Slack for any questions regarding credentials sync, ensuring a straightforward line of communication. - **Time zone consideration:** With Kanish located in India, there is an approximate 3-4 hour time difference, which will be factored in when scheduling any potential calls for deeper discussions. ### **Implementation of a Temporary Storage Solution** A decision was made to utilize the existing Microsoft SharePoint infrastructure as a temporary storage repository for client bills, avoiding the need to build a custom solution. - **Leveraging existing licenses:** The company's Microsoft Business Premium licenses provide ample SharePoint storage (approx. 10GB per user), which is already available to all operators. - **Initial setup and access:** A dedicated SharePoint site named "Arcadia Files" has already been created. The site owners will verify operator access and are responsible for organizing the folder structure, which can be arranged by client for easier management. - **Ownership and permissions:** The necessary individuals are designated as owners of the SharePoint space, granting them full control to create folders and manage content as needed for the onboarding process. ### **Firewall Configuration for AppSmith Integration** A request was made to whitelist the IP addresses for AppSmith, a data visualization tool, to allow it to pull data from internal databases. - **Security and scope clarification:** The request requires specific details on which parts of the infrastructure (e.g., specific databases or services) need to communicate with AppSmith to ensure proper and secure firewall rules. - **Purpose of the tool:** AppSmith is intended to create editable, dynamic dashboards and reports, primarily for UBM data but with expanding use for DS data as well. - **Action item:** The relevant team will review the specific IP details posted in the dedicated communication channel and proceed with the whitelisting process on the DS side, mirroring what was previously done for UBM. ### **Enhancements to Output Service Validation** Work is planned to improve the output service by implementing a mechanism to handle validation failures appropriately, ensuring failed bills are routed for manual review. - **Current status:** A previous issue with a stored procedure in the output service has been resolved, and the service is currently functioning for single-bill processing. - **Proposed improvement:** The focus is on adding logic so that when a bill fails validation during output processing, it is automatically sent to a "data acquisition audit" workflow where operators can intervene. - **User experience consideration:** To aid operators, any bill kicked back to audit will include a note within the system explicitly stating the reason for the failure, providing immediate context for corrective action. - **Next steps:** The implementation will involve brainstorming the specific integration points within the existing DS state workflow and beginning development on this new error-handling path.

## Summary The meeting focused on troubleshooting and clarifying the expected behavior of the DSS auto queue system, particularly regarding how user updates to pending items should be processed. ### DSS Auto Queue Process and Update Behavior The core discussion revolved around the automated workflow for items in the DSS auto queue. The key point clarified was that when a user submits an update to an item within this queue, the system should automatically progress that item to the next stage in its workflow. This confirmation resolved a point of prior confusion, indicating that manual intervention to move the item forward should not be necessary after an update is saved. - **Automated progression upon user update**: The system is designed to handle updates seamlessly, moving the item to the next stage automatically once the user submits their changes. This addresses a potential gap in understanding where a team might have been waiting for a separate manual step. ### Example of a System Inconsistency An immediate practical example was raised to test the confirmed understanding, pointing to a potential data or display issue within the system itself. A specific field in a record was noted to show an unexpected value ("1300"), which contradicted other available information. - **Addressing data discrepancies**: While the process for handling updates was clarified, the conversation highlighted an instance where the data presented to the user might be incorrect or inconsistent, suggesting a separate issue that could affect user trust and system reliability.

## Customer The customer is an energy supplier or utility company, likely operating under the "Constellation" brand, which utilizes the platform for invoice processing and management. They appear to be a sophisticated user, engaged in a detailed operational workflow that involves pulling and reconciling utility bills on behalf of their own customers. Their background involves managing complex data integrations and ensuring accurate financial transactions through the system, indicating a mature and critical use of the service. ## Success A notable success highlighted is the customer's proactive and diligent oversight of their account security and user management. Specifically, the customer (referenced as BPG) identified unfamiliar "Cognizant" usernames with external email addresses on their account and actively questioned who these users were. This level of scrutiny is described as exceptional, demonstrating that the customer is thoroughly engaged with the platform's user audit features and is vigilant about access control. This incident validates the value of the platform's transparency but also underscores that this particular customer operates with a high standard of internal governance. ## Challenge The primary challenge revolves around significant data integrity and system integration issues. There is a persistent problem with customer accounts and invoices not being correctly set up or reflected in the system. For instance, some accounts were not properly registered in the core database despite being in the upstream system, leading to invoices not processing. Furthermore, there is considerable confusion and inconsistency around critical data fields, such as "total charges" versus "total amount due," which impacts accurate financial reporting and reconciliation. An additional, recurring pain point is the visibility of internal support or implementation team members within the customer's user list in the platform, which causes confusion and concern for the customer when they see unknown individuals with access. ## Goals - Achieving seamless and error-free invoice processing and data acquisition from utilities. - Establishing clear and accurate data mapping, particularly for financial fields like total payment amounts, to ensure reliable reporting. - Improving the user management experience within the platform, ideally by masking or clearly designating internal support personnel to prevent customer confusion. - Gaining better visibility into the processing lifecycle beyond SLA metrics, such as tracking against invoice due dates, to manage internal workflow more effectively. - Cleaning up legacy data and tickets (e.g., items in "OPS review") to maintain a clear and actionable system record.

## الملخص النص المُقدم للتحليل قصير جدًا ولا يحتوي على أي محتوى جوهري أو نقاشات فعلية حول أي موضوع. يتكون النص بشكل كامل تقريبًا من تكرار عبارة "ممتاز 45 دقيقة" دون أي سياق أو تفاصيل توضح سبب هذا الوصف أو ما هي الفكرة أو المشروع الذي يتم مناقشته. بالتالي، لا يمكن استخلاص أي نقاط نقاش مهمة، ولا توجد مواضيع ذات معنى لتقسيمها إلى أقسام فرعية. الملخص للاجتماع، بناءً على النص المقدم، هو أنه لم يتم مناقشة أي موضوع عملي أو إداري، ولم يتم تبادل أي معلومات ذات قيمة يمكن تلخيصها.

## **العميل المحتمل** العميل هو مؤسس لديه خبرة في مجال التصميم والخدمات الإبداعية المعززة بتقنيات الذكاء الاصطناعي. يتمتع بخلفية تقنية تمكنه من استخدام أدوات متقدمة مثل "جيميني" (Gemini) لتوليد الصور والفيديوهات، بالإضافة إلى الاعتماد على منصات مثل "فيجما" (Figma) في عمليات التصميم. يتبنى نهجاً ريادياً واضحاً، حيث يصر على البحث عن شريك أعمال (Co-founder) يمكنه المشاركة في المسؤوليات والبناء، وليس مجرد موظف. يعمل حالياً بشكل فردي إلى حد كبير، ويشرف شخصياً على التواصل مع العملاء الحاليين وإدارة سير العمل. ## **الشركة** تدور أعمال الشركة حول تقديم خدمات تصميم متخصصة، مع التركيز على استخدام قوالب (Templates) مخصصة ونماذج ذكاء اصطناعي لتحسين الجودة والكفاءة. يبلغ إيرادها الشهري المتكرر (MRR) حوالي 9000 دولار أمريكي، وتخدم حالياً أربعة عملاء، بعضهم مشتركون بخطط سنوية. تستخدم الشركة مجموعة من الأدوات التقنية مثل الحوسبة السحابية (Cloud) ومنصات التواصل المباشر (مثل واتساب) لإدارة المشاريع والتواصل. تواجه الشركة مرحلة نمو تتطلب تطوير العمليات الداخلية لأتمتة المهام وزيادة القدرة الاستيعابية لاستقطاب المزيد من العملاء. ## **الأولويات** - **تحقيق قابلية التوسع (Scalability):** تُعد الأولوية القصوى، حيث أن قدرة المؤسس الحالية على استيعاب عملاء جدد محدودة بسبب انشغاله الكامل بإدارة العملاء الحاليين. هناك حاجة ملحة لأتمتة العمليات الداخلية وبناء أنظمة تسمح بإضافة عملاء بدون تضييق على الوقت والجودة. - **هيكلة تواصل فعّال مع العملاء:** يعتمد التواصل الحالي بشكل كبير على القنوات المباشرة وغير الرسمية مثل واتساب، مما قد لا يكون مستداماً مع نمو عدد العملاء. هناك تركيز على البحث عن أدوات أو إجراءات أكثر تنظيماً لمراجعة التصاميم وتبديل الملاحظات مع العملاء بطريقة مركزة وفعّالة. - **الموازنة بين العمل عن بُعد والتواصل الشخصي:** يؤمن العميل بأهمية التفاعل المباشر وبناء العلاقات الشخصية، حتى في إطار عمل رقمي. يناقش أهمية تبني نموذج عمل هجين (Hybrid) يتضمن لقاءات دورية مكثفة لفريق العمل لتعزيز الروح الجماعية والابتكار المشترك، مع الإبقاء على مرونة العمل من أي مكان. - **تأمين التمويل والنمو المستدام:** هناك اعتراف بالحاجة إلى رأس مال (Capital) لتمكين النمو، سواءً لتمويل التطوير التقني أو لتوفير رواتب ثابتة عند إحضار شركاء أو موظفين. يتم النظر في نموذج شراكة عادلة يأخذ في الاعتبار مستوى الالتزام والوقت المخصص من قبل الشريك المحتمل.

## Background The candidate has a strong product management background, often acting as the "glue" between engineering, product input, and operations to drive product strategy. Their career path includes consulting, followed by a role at the Finmark OIC startup, and most recently, a significant tenure at Build.com. At Build.com, they played a key role in leading the product vision and foundational work, particularly during and after acquisitions. ## Work Experience The candidate's experience is characterized by tackling complex integration and platform challenges. Their most relevant tactical experience comes from their time at Build.com following the Finmark acquisition. They led the effort to create a unified platform by merging features from three distinct systems: the existing Build platform, the Finmark product, and another acquired company, Devi. This involved defining the vision for "Build 2.0," which ultimately became the foundation for the current Build.com platform. Their approach to such large-scale, cross-functional collaboration is methodical and highlights several key insights: - **Ownership and Alignment:** Success hinges on assigning clear product ownership for each application component and ensuring those owners' direct managers are fully aligned on goals and timelines. - **Managing Dependencies:** A primary challenge is securing the right resources, especially from teams outside one's direct control, due to inevitable external dependencies. - **Technical Vision:** It is crucial to have the right technical leadership involved from the start to make decisions that support a long-term, sustainable vision rather than just a quick fix. Currently, at Constellation, the candidate is applying this experience to untangle systemic issues. They identify two core problems: a "house of cards" architecture where solutions are built in isolation and become brittle, and a cultural "mindset shift" needed to challenge long-held operational assumptions that may be contributing to technical debt. Their work focuses on deliberate refactoring of broken, siloed components to create a modular, scalable foundation, starting with critical data services. ## Candidate Expectations ### Working Style The candidate expects and thrives in a highly collaborative environment. They emphasize the importance of breaking down silos, not just technically but interpersonally. They believe in empowering team members to communicate directly with the right people across engineering and operations without unnecessary gatekeeping or bureaucratic hurdles. Their ideal work mode involves being the connective tissue between strategy and execution. ### Career Goals Professionally, they are focused on moving the organization from a short-term, fire-fighting mentality to a strategic, product-first, and platform-oriented approach. They aim to establish scalable systems and processes that will support long-term growth, specifically by transforming the platform to reduce manual operational overhead and custom one-off solutions. ### Specific Needs To be effective, the candidate needs direct access to knowledge and the authority to question existing processes. They note a current struggle where they are not always equipped with the necessary information, and when they consult subject matter experts, underlying assumptions are often not challenged. They seek an environment where "everything is on the table" for reevaluation to solve root causes, not just symptoms. ## Questions/Concerns The candidate's questions reflect a deep engagement with the company's strategic challenges. They sought validation on their diagnosis of the core issues, asking if the panel agreed on the major problem areas: chronic data acquisition timeliness, persistent data inaccuracies, and poor integration between key applications (Data Services, UBM, Carbon Accounting, Glimpse). Furthermore, they implicitly raised concerns about the company's ability to transition from a "services-first" and custom-reporting culture to a true product-led, scalable SaaS model, given the existing commitments and business structure.

## Summary The meeting focused on resolving several ongoing technical challenges and planning a new workflow to streamline data operations. Discussions centered on system integrations, infrastructure access, and developing a temporary solution for managing critical documents. ### Power BI Account and Pipeline Deployment A solution has been developed for a previously stalled Power BI integration. While Microsoft support was unhelpful, an internal resource successfully rewrote the necessary components. The revised code is now ready but not yet in production. The next step involves running a specific deployment pipeline to activate the service in the live environment, which is described as a safe, intermediate-step process designed to avoid breaking existing systems. The status check and restart pipeline must be executed in sequence to ensure a correct deployment. ### FTP Server Access and File Retrieval There was clarification on how to access and retrieve files from an internal FTP server. Access is tied to the corporate domain VPN, and users should already have the necessary credentials. The discussion covered practical methods for connection, recommending either using a Remote Desktop Protocol (RDP) session into a virtual machine or employing an FTP client like FileZilla. A specific issue was raised about potential security software on Windows machines blocking file execution, with the suggested workaround being to copy files directly from the VM via RDP rather than trying to install or run them locally. ### Proposed Arcadia PDF Management Solution A significant portion of the meeting was dedicated to planning a new, temporary workflow to handle utility bills from Arcadia, aiming to drastically reduce manual work for the Data Operations (DS Ops) team. **The Proposed Workflow** The plan involves automatically downloading PDF invoices from the Arcadia provider API as soon as they are available. These files, named with the relevant customer account number, would then be placed in a shared folder. DS Ops personnel would access this folder, identify the correct PDFs, and manually upload them into their processing system (Web Download Helper or DSS), bypassing the need to log into individual utility portals. **Critical Infrastructure and Access Considerations** The primary unresolved question is identifying the appropriate shared storage location that all relevant team members can access securely. Key constraints and considerations were identified: - **Access Requirements:** The solution must be accessible to all DS Ops team members, including the Mexico-based team, who may or may not have VPN access to the core infrastructure. - **Security Concerns:** Providing full VPN access to the production infrastructure to all operators was flagged as a potential security risk and should be avoided. - **Platform Options:** Several platforms were discussed as potential hosts for the shared folder, including a SharePoint folder (likely available with existing business email accounts), an Azure storage blob with a SharePoint front-end, or a third-party service. The core requirement is a simple, shared space accessible with existing company credentials, without requiring additional VPN configurations. - **Next Steps:** The action is to research and define the simplest, most secure shared storage solution that meets the access requirements, with findings to be discussed in a follow-up meeting. ### Pending Tasks and Follow-ups A separate issue regarding report analysis was noted as pending, awaiting a whitelist approval that is expected to be resolved on Monday. The overall direction for the Arcadia project will be solidified with more detailed requirements and a drafted plan in the immediate future.

## Architectural Integration and Scalability The meeting centered on the urgent need to establish a cohesive architectural framework for integrating Arcadia across the organization's applications, such as Navigator, DSS, and UVM. The current piecemeal approach, relying on manual processes to connect with Arcadia and download customer invoices, is unsustainable and creates conflicts, especially with shared clients. A long-term, scalable solution is required to manage customer IDs, send uniform notifications, and maintain a consistent data structure. - **Establishing a Unified Data Architecture:** The core proposal is to develop a shared Navigator database or user base. This system would pull data from Arcadia once and distribute it intelligently across all relevant applications, ensuring all teams operate from a single source of truth and can communicate effectively to avoid future conflicts and duplication of effort. ## Immediate Operational Goals with Arcadia The primary immediate objective is to leverage Arcadia to solve the most pressing operational bottleneck: the time it takes to download and process customer invoices, which currently averages around seven days. The strategy is to implement a phased approach, starting with a manual but faster process, while building the foundations for full automation in parallel. - **Phase 1: Manual PDF Download and Distribution:** The first milestone is to use Arcadia simply as a fast download source. Invoices will be pulled and placed into pre-defined, customer-specific folders on a shared directory. A manual cleanup process for this folder will be established (e.g., data purged every two weeks) to manage the influx. This step alone is expected to dramatically reduce the initial 7-day delay. - **Phase 2: Laying the Groundwork for Automation:** Concurrently, the team will work on the technical prerequisites for automation. This includes implementing clean credential logging to track Arcadia API calls and errors, and establishing a reliable webhook system from Arcadia to receive real-time notifications when new bills are available, which is critical for eliminating guesswork and assumptions in the billing cycle. - **Parallel Operational Streams:** It was emphasized that work on non-Arcadia-related processes (like template builds and ICDB cleanups) must continue. The goal is to fold Arcadia into the organization's optimized workflow rather than creating a separate, permanent "Arcadia work stream." ## Credential Management and Data Mapping A significant immediate blocker is the inconsistency in customer credentials stored across different systems (DSS and UVM). Cleaning and unifying these credentials is a prerequisite for successful and accurate automated data pulls from Arcadia. - **Credential Cleanup Process:** A dedicated operational resource is needed to review and correct credential mismatches. A new tool has been developed to highlight discrepancies-such as usernames/passwords that differ between systems or accounts that exist in one system but not the other. For a sample customer, mismatches numbered in the dozens, indicating a manageable but critical cleanup task. - **Data and Vendor Mapping:** Beyond credentials, there is a need to resolve vendor name mismatches between internal records and Arcadia's listings (e.g., "First Energy" might be listed under a different name in Arcadia). A separate list of approximately 30 such vendors requires review and mapping to ensure complete coverage. ## Team Structure and Resource Requirements To execute the plan, specific roles and resources were identified as necessary for both immediate tasks and long-term architectural success. - **Immediate Operational Support:** Two key roles are needed urgently: - A credentials specialist to systematically clean up the credential mismatches using the new tool. - An operations team (potentially leveraging an existing overseas team) to manage the manual process of downloading invoices from the new Arcadia-sourced folders and handling them through the existing workflow. - **Long-term Architectural Support:** The team identified a gap in solution architecture expertise. A dedicated solution architect is required to design the sustainable, high-level data flow and integration patterns that will allow Arcadia data to be used seamlessly across the entire Navigator platform (UBM, Carbon Accounting, etc.), ensuring the solution is built correctly for future scale. ## Preparation for Leadership Presentation The conversation shifted to preparing for an upcoming presentation to key business leaders, including Jim, Dan, and George. The goal is to showcase the platform's capabilities and its strategic role in feeding multiple business units. - **Presentation Structure and Key Messages:** The presentation will start by positioning the platform as the central "engine" that feeds critical services like Corporate Sustainability, Navigator Rebates, and retail commodity offerings. It must highlight collaboration with other teams and demonstrate how the platform adds value across the organization. - **Content Guidance and Cautions:** Specific advice was given to tailor the message for the audience: emphasize the retail/SaaS application first, as it aligns directly with sales strategy, and be prepared to discuss applicability to gas customers. A caution was raised to avoid mentioning a specific reference customer (Core Weave) due to its recent public financial difficulties.

## Status Updates and Current Work Focus A round of status updates was given, primarily focused on the ongoing development and refinement of internal tools and reports. The key areas of work involve the credential management system, the data synchronization between UBM and DS tables, and resolving discrepancies in the late-arriving bills report. ## Credential Management System Development Significant progress was made on the credential management interface, which has been deployed to the test and development servers. The updates enable comprehensive handling of credential data through a dedicated management page. - **Enhanced UI and Functionality**: The logic and user interface for creating, editing, and deleting credentials have been updated. The system now displays columns from a new consolidated table, including mandatory fields like mark, source, and timestamps. - **Discrepancy Resolution Workflow**: Credentials can now be resolved directly from the validation page, after which they appear on the management page for further edit or delete operations. - **Dynamic Form Fields**: The "create credential" modal on the management page now includes dropdowns for vendor, client, and account, allowing for the creation of new credentials for specific combinations. **Data Synchronization Strategy** A shift in the data-fetching approach was discussed to optimize performance. Instead of dynamically pulling from both source systems (UBM and DS) in real-time, a new method is being implemented where all records are fetched and stored in a single table within DS. A sync mechanism will update this consolidated table whenever a new credential is added or an existing one is modified in the source systems. A crucial future requirement noted was the need for **bidirectional sync**: any updates made in the new management system must also be propagated back to the original UBM and DS tables, as those are still actively used by other teams. ## Review and Next Steps for Credential Management A live review of the test environment was conducted to align on the current state of the feature. It was confirmed that the system correctly displays discrepancies (e.g., records existing in only one system or having different passwords) and allows users to select a source of truth to resolve them. Feedback was noted regarding making the URL a required field and the description optional. A detailed list of items, including the bidirectional sync requirement, will be formalized and shared to guide the next phase of development. ## Deployment and Production Updates Several features have been successfully promoted to the production environment following verification in test. The **bill upload data** feature and the **editable template** functionality within the activity history are now live. Furthermore, work has commenced on a separate project cycle related to FDG Connect, which is distinct from the main DSS application. ## Investigation into Late-Arriving Bills Report A critical issue was raised regarding a mismatch between the "Late Arriving Bills" report and the master accounts list. The report appears to show fewer late bills than expected, prompting a need for investigation. - **Identifying the Discrepancy**: The current report only includes accounts that have already received at least one bill, while the master list contains all accounts. The logic for identifying a "late" bill is based on whether the current date has passed the projected invoice date for that account. - **Scope and Logic Analysis**: A key finding was that the late bills report only considers two bill source types (Web and Mail), whereas the master account list tracks four types. It was emphasized that all bill sources must be tracked for accountability, as the team is responsible for timely payment regardless of how the bill is expected to arrive. - **Plan for Resolution**: The immediate action is to add an "All" filter to the late bills report for broader visibility. The core task is to investigate why applying the same "late bill" logic to the full master accounts list yields a different count than the current specialized report. This may involve creating a new filtered view of all accounts to compare data directly. The team will also examine the specific conditions other teams are using to manually generate their own late reports to ensure alignment.

## **Summary** The meeting focused on planning the technical integration with Arcadia, a utility data platform, to automate the retrieval of customer invoices (PDFs) and manage the associated credentials. The discussion centered on understanding current processes, defining new automated services, and solving key data mapping challenges between multiple internal systems (DSS and UBM) and Arcadia's API. ### **Project Overview and Goals** The primary objective is to automate two core processes currently handled manually: sending customer credentials to Arcadia and pulling historical invoice PDFs from their platform. This automation is crucial for scaling operations and ensuring data consistency across systems. - **Automating Credential Management:** The current manual process of uploading credentials via CSV to Arcadia's dashboard is not scalable. The goal is to build a service that can programmatically send and, more importantly, monitor the status of these credentials (e.g., "connection success," "MFA required," "invalid credential"). - **Automating Invoice Retrieval:** The manual method of calling the Arcadia API to fetch PDFs needs to be replaced with a reliable service. This service should be capable of pulling invoices for a specific client over a defined date range, which will support both ongoing operations and the onboarding of new clients who require historical data. ### **Automating Credential Status Monitoring** A critical first step is gaining visibility into which client accounts in Arcadia are active and which have failed. This involves creating a new service to synchronize Arcadia's credential status with internal records. - **Initial Implementation Plan:** The first technical task is to write a script that will iterate through all account numbers for a specific client (starting with Ascension). For each account, it will call the Arcadia API's credentials endpoint to retrieve the current connection status. - **Data Storage Strategy:** The information fetched from Arcadia (status, failure details) will be stored in a new database table. This table will link the internal account record with its corresponding Arcadia account ID and status, providing a single source of truth for credential health. This is essential for the Data Operations team to review and take corrective action on failed accounts. - **Open Questions:** A significant unresolved question is whether these API calls for checking status will incur costs, as the enterprise pricing agreement with Arcadia is not fully detailed. The decision was to proceed cautiously with the first client to understand the implications. ### **Building the Historical Invoice Pull Service** Beyond checking credentials, a dedicated service is needed to actually retrieve the invoice documents from Arcadia. This service must be flexible to handle both one-time historical pulls and future automated updates. - **API Workflow Clarified:** The process for fetching a PDF involves two API calls. First, a search with the account number yields a unique Arcadia account ID. Second, using that ID, a call to the statements endpoint retrieves a list of available invoices, each with its own statement ID. Finally, the statement ID is used to download the actual PDF. - **Service Design:** The envisioned service will accept parameters like client, vendor, account number, and a date range. It will then execute the API workflow to pull all corresponding PDFs within that period. This design will support onboarding new clients (by pulling their full history) and supplementing data for existing clients. - **Learning from Past Mistakes:** It was noted that previous manual pulls fetched *all* available data without filters, which was inefficient. The new service must include proper query parameters to fetch only the necessary data. ### **Data Mapping and Integration Challenges** A major architectural challenge discussed was ensuring the accurate mapping of invoices from Arcadia to the correct records in the internal DSS and UBM systems, given that all three systems have different identifiers. - **The Unique Identifier Problem:** While the Arcadia API can be queried with just an account number, there is concern that this may not be a unique enough key, especially if a single credential provides access to multiple sub-accounts. The unique `account id` returned by Arcadia in the initial API response was identified as the crucial linking field. - **Creating a Mapping Layer:** The solution is to create a mapping table or add columns to an existing table (like the client account table) that stores the relationship between the internal client/vendor/account composite key and the unique Arcadia account ID. This mapping is vital to ensure every pulled PDF is correctly associated in both DSS and UBM. ### **Technical Implementation & Next Steps** The conversation concluded with concrete plans for initial development and broader technical alignment. - **Immediate Action Items:** The immediate focus is on the Ascension client. The first step is to build the script and table for credential status synchronization. Following that, development will begin on the historical pull service for PDFs. - **Broader Technical Context:** The credential automation is part of a larger "credential validation" epic being worked on separately, which aims to resolve discrepancies between credential storage in UBM, DSS, and external sources like Smartsheet. - **Environment Setup:** A separate goal was established to provide local development environment access for the codebases (DSS API, DSS UI, IPS API) hosted in Azure DevOps, to enable future work and experimentation. ### **Ancillary Technical Topics** Brief time was spent addressing two unrelated but urgent technical issues. - **Power BI Dashboard Issue:** An investigation is needed into why a Power BI report is not displaying data beyond January 13th, with a suspicion that a backend query or connection may have failed. - **DSS Build List Filter:** A separate UI issue was identified where the date filter in the DSS "all bills" view seems to be hard-coded or malfunctioning, preventing users from seeing bills after January 13th. This requires a front-end or query fix.

## Overview of Billing and Output Service Issues This meeting focused on critical operational challenges within the billing data pipeline, primarily concerning the Output Service and its interaction with upstream systems like Data Services (DSS) and Data Audit. The core problems identified included incorrect data propagation, systemic bottlenecks causing processing delays, and a lack of cohesive validation across the workflow. The discussion centered on diagnosing the root causes and formulating a strategic plan to enhance data integrity and system reliability. ## Resolving Incorrectly Loaded Bill Data **The immediate priority was addressing bills that had been imported into incorrect client-vendor accounts within the data systems.** This misallocation risked creating "gap bills" for customers, where a processed but wrong bill would prevent the correct one from being pulled, disrupting financial reporting. - **Proposed Solution and Process:** A plan was established to completely delete the affected document batches from the Data Services System (DSS). A technical lead confirmed the availability of a targeted delete query for document batches, which would effectively wipe all associated data and allow the system to repopulate the correct download tasks. - **Coordination:** Action was delegated to provide the specific bill or batch IDs via a dedicated team channel so the deletions could be executed precisely, cleaning the data slate before further processing. ## Systemic Bottlenecks in the Output Service **The Output Service was identified as a major bottleneck, causing significant delays in bill delivery to customers.** This was exacerbated by a shift from batch processing to individual bill processing, which unintentionally amplified the impact of validation errors. - **Processing Delays and Business Impact:** The service was not processing bills quickly enough, leading to a growing backlog in the "Ready to Send" queue. This delay was particularly critical for priority bill-pay customers (e.g., prepay and UEM service levels), where on-time payment file generation is contractually essential. Manual intervention to push bills was frequent but inconsistent. - **Root Cause Analysis - Validation Failures:** The primary driver of the backlog was a high volume of bills failing the Output Service's validation checks-estimated at 800 bills. These validations were originally intended as a rare, final check but are now catching frequent errors. Key failure points include missing or invalid invoice dates and incomplete client service item setups. - **Amplification by Architectural Change:** Moving to per-bill processing meant that every bill with a validation error required its own data fetch. This caused the system to waste cycles repeatedly checking and failing the same invalid bills, drastically slowing overall throughput. The absence of a separate quarantine queue for failed items meant these bills remained in the active processing loop. ## Critical Gaps in Data Validation Workflow **A fundamental disconnect was uncovered between validation steps in DSS/Data Acquisition and the final Output Service check, allowing erroneous data to flow to the last stage.** This gap is largely due to increased use of "audit skip" functionalities. - **Source of Invalid Data:** A significant portion of problematic bills originates from DSS or from processes where audit steps are skipped. Unlike data entered through the traditional Data Acquisition (DDAS) system-which has robust, integrated validation-these bypassed streams lack the same rigorous automated checks. The result is that invalid data is only caught at the final output stage. - **Human Audit Bypass:** Due to past resource constraints, a policy was enacted to skip human data audit for many bills, relying on the assumption that automated systems were accurate. This has led to downstream errors, including incorrectly labeled client bills (e.g., Arcadia badges on wrong accounts), which the UBM team was unprepared to handle. - **The Client Service Setup Dilemma:** A specific, persistent validation error relates to client service configuration (e.g., charge-only lines with incorrect units). This is an account-level issue, not a bill-level one, and is not validated during data entry or account setup. Fixing these requires editing the client's master service items, not re-auditing individual bills. ## Strategic Solutions and Proposed Workflow Changes **The consensus was to implement upstream validation parity and intelligent failure handling to resolve the core issues.** The goal is to catch errors earlier and prevent them from clogging the final output stage. - **Implement Unified Pre-Audit Validation:** The primary strategy is to align the validation logic in DSS and Data Acquisition with the checks performed by the Output Service. Bills failing these checks in DSS would be routed directly to Data Audit for human review *before* ever reaching the "Ready to Send" queue. This should prevent ~80% of current output failures. - **Redesign Failure Management:** For bills that still fail at the output stage, a new process is needed: - Bills with data errors (e.g., bad dates) should be pulled back to Data Audit for correction. - Bills failing due to **client service setup** issues should *not* go to audit, as the bill itself is fine. Instead, an alert should trigger the account management team to fix the master client service items. - **Optimize Output Service Performance:** Short-term tactical fixes include manually pulling all bills stuck in "Postpay" or "History" back to audit to clear the processing queue. This will allow the Output Service to focus only on valid, ready bills. A **priority queue** for prepay/UEM customers is also planned for implementation to ensure critical deadlines are met. - **Enhanced Monitoring and Debugging:** Additional detailed logging will be added to the Output Service to better track the lifecycle of each bill and diagnose why manual pushes sometimes fail or delay. This will help identify and fix elusive issues, such as system queries incorrectly returning zero bills for a batch.

## Summary The meeting centered on resolving critical operational issues, planning strategic integrations, and addressing upcoming compliance deadlines. A major data ingestion problem was analyzed, solutions for system safeguards were discussed, and significant upcoming projects were reviewed with attention to resource allocation and timelines. ### Arcadia Data Ingestion Incident and Immediate Fixes An urgent issue was addressed concerning incorrect data from the Arcadia P7 source being ingested into the wrong client accounts, requiring both immediate correction and the creation of a preventative system safeguard. - **Nature of the Problem:** Instead of creating new accounts, incorrect PDF bills (e.g., for "Sheets") were mapped to and ingested into existing accounts for different clients (e.g., "Victra"). This occurred because the file names matched the wrong client accounts during the upload process by the Data Operations team. - **Immediate Action:** The corrective workflow involves marking all affected bills for deletion and resetting the download status. This ensures that if a bill is legitimately due, it will reappear as a task for manual download, preventing missed bills. - **Long-term Technical Safeguard:** A new validation step will be added at the bill processing stage. The system will check if the account number and other key identifiers on the incoming bill PDF match the account it is being uploaded to. Any mismatch will halt the process and route the bill to a manual validation queue for review before proceeding, preventing similar errors in the future. ### Credential Management and Arcadia Integration Planning Progress on a credential management system was confirmed, and comprehensive planning for the permanent Arcadia integration, referred to as the "Arcadia Dashboard," was outlined. - **Credential Management System:** This project is on track, with a push to the testing environment expected imminently and a target production release early the following week. - **Arcadia Integration PRD:** A detailed Product Requirements Document (PRD) has been drafted to formalize the long-term solution. This document covers the API integration, metadata capture, data flow, and cloud infrastructure. A technical review is scheduled to validate the approach, identify dependencies, and break down the work into parallel or sequential tasks. - **Strategic Data Tracking:** A key driver for the new dashboard is the need for comprehensive, client-agnostic file tracking. The current lack of visibility creates challenges when clients dispute whether files they've sent have been processed. The new system aims to provide an audit trail from the original source file all the way to the final processed bill, answering these questions definitively. ### Q3 Project Portfolio and Resource Constraints The quarter's project load was reviewed, highlighting significant overlap between major initiatives and raising concerns about developer bandwidth. - **Key Q3 Deliverables:** The quarter includes three major concurrent efforts: the **Azure cloud migration**, the annual **SOC 1 Type 2 audit renewal**, and the first-time implementation of a **SOC 2 Type 2 certification**. - **Bandwidth Concerns:** The Azure migration is expected to heavily occupy the primary DevOps engineer. Simultaneously, the two SOC audits require substantial evidence gathering and process documentation from the development and infrastructure teams, creating a potential resource conflict. - **Proposed Mitigation:** To address the compliance workload, the idea of hiring or assigning a dedicated, tech-conversant project manager was discussed. This person would coordinate evidence collection, manage vendor (Eden) communications, and handle ticket management, thereby reducing the burden on the core engineering leads. ### SOC 2 Certification and Client Commitments The initiation of the SOC 2 Type 2 certification process was confirmed, driven by specific client demands and upcoming contracts. - **Project Initiation:** Work has begun on the first-ever SOC 2 Type 2 certification for the organization. An internal expert who has previously managed such projects will lead the evidence management effort. - **Business Imperative:** The project is critical for business development, as at least one potential client (L'Oréal) is preparing to sign a contract contingent on achieving SOC 2 compliance within the calendar year. Another existing client also requires it. ### Communication and Operational Strategy Actions were defined to improve internal communication and set clear expectations for the team regarding operational changes. - **Streamlining Communication:** To prevent context loss from numerous direct messages, all technical discussions related to data systems development will be centralized in a dedicated Slack channel. This ensures broader awareness and more efficient information sharing within the team. - **Managing Team Expectations:** A leadership-facing view of the Arcadia integration's impact will be prepared. The goal is to transparently show the team that while Arcadia will resolve a large percentage of manual work, new categories of tasks (managing non-covered vendors, handling MFA/credential issues, and addressing the remaining "delta") will emerge. This clarity is intended to prevent surprise and ensure proper resource planning for the new operational model.

## **Project Background and Current Challenges** The meeting centered on the Simon project, a client contract signed in July, where onboarding only began in mid-November after the client expressed frustration over delays. The core challenge is defining and developing critical financial reports required for go-live, a process complicated by the recent passing of the client's key knowledge holder. New report requirements continue to surface unexpectedly, and the client's team lacks a clear inventory of who uses which reports, forcing the project team to reverse-engineer specifications by interviewing users. ## **Analysis of Go-Live Readiness and Risks** The group thoroughly assessed the feasibility of the current April 1st go-live date and unanimously agreed it is unattainable and risky. - **Unrealistic Timeline:** Even with complete specifications today, development is estimated at 45 days, not accounting for subsequent client testing and approval cycles. A key dependency is the client's 60-day notice period to their current vendor (NG), which would have needed to start immediately to hit an April 1st date. - **Significant Financial and Reputational Risk:** Going live with incomplete or incorrect reports would cause major financial and SOX compliance issues for the client. The consensus was that this would ultimately damage the relationship, as the provider would be blamed for the failure, regardless of the root cause being unclear client requirements. - **Consensus for a New Date:** The team agreed that a **June 1st go-live date** is a realistic and necessary target. This provides a clear timeframe for the client to manage their vendor notice and allows both teams a concrete goal. ## **Deep Dive into Report Requirements and Status** A major portion of the discussion involved scrutinizing the specific reports needed, their status, and the obstacles in finalizing them. - **Expanding and Unclear Specifications:** What was originally thought to be three reports has now grown to at least seven. The client's risk-averse culture leads them to request "all the data" without a clear understanding of what is essential, complicating development scope. - **Current Completion Estimates:** - **Payment Files (CSV & Text versions):** These are approximately 80% defined, though a crucial GL mapping from the client is still pending and could alter the build. - **Anaplan Feed Files (Bill Info & Vendor Info):** These are new requirements. While similar to existing reports, they require new GL allocation logic, making them more complex than simple column matching. - **GL Allocation Report:** A new requirement similar to an account-side report; specifications are still undefined. - **Accrual (CT) Report:** A complex, detailed report used for year-end reconciliation. The team strongly advocates for this to be a post-go-live deliverable, as it is not a day-one necessity, but the client currently insists on its inclusion. - **Process Anomalies:** The team discovered the client's data contains consolidated line items (e.g., water/sewer combined) and a large "other charges" bucket without clear mapping. Resolving how to handle these-or if the client even wants them changed-requires senior client direction. ## **Dependencies and Logistical Hurdles** Beyond report development, several other critical path items were identified that support the need for a delay. - **LOA and Account Onboarding:** The Letter of Authorization (LOA) for EDI accounts cannot be pursued until the client gives notice to NG. Without the LOA, portal setup and credential changes for thousands of accounts cannot begin, a process estimated to take at least 30 days. - **User Management:** A process for user provisioning and de-provisioning via a single sign-on (SSO) feed is still an outstanding development item that needs to be scoped and built. - **Extended Testing Phase:** Given the large number of stakeholders and the client's risk-averse, detail-oriented nature, the User Acceptance Testing (UAT) phase is anticipated to be lengthy and must be factored into the timeline. ## **Proposed Strategies and Path Forward** The team discussed proactive strategies to build client confidence and demonstrate progress while working toward the new June 1st date. - **Phased Data Rollout for Familiarization:** A proposal was made to provide the client with live platform access using a subset of their real data (e.g., Constellation accounts) well before the go-live date. This would allow users to explore the system, generate questions early, and become comfortable with the new platform, potentially reducing last-minute confusion. - *Technical Note:* This would involve manually running processes to generate sample AP files, as the system wouldn't process them automatically in a "history" state. - **Financial Recognition for Work:** The idea of discussing partial billing for the onboarding and report development work completed to date was floated, similar to a past approach with another client, to recognize the effort invested. - **Communication Plan:** The team agreed that the rationale for the June 1st date and the suggestion of a phased data rollout should be communicated directly to the primary client stakeholder (Drew) in a focused conversation, not on a large group call, to manage the message effectively.

## **Introductions and Project Scope Clarification** The meeting began with introductions of team members and a new participant shadowing the project for learning purposes. The core discussion clarified the nature of the project work, emphasizing that it involves improving multiple distinct business processes for efficiency and automation, rather than optimizing a single, end-to-end workflow. A key administrative point was addressed regarding a requested process map; it was clarified that the request was actually for a project timeline update to show completed and in-progress work for leadership reporting, not a detailed process document. ## **Review and Confirmation of Completed Multi-Month Initiatives** Several initiatives marked for completion in previous months were reviewed and formally confirmed as finished by the team. This ensures the project plan accurately reflects progress. - **Establish New Credentials:** This task was confirmed as complete, with a clear distinction made that it was separate from the ongoing, related "UBM Credential Management" work. - **Customer Issues (Phase 1 & 2):** Both phases of addressing customer issues were validated as completed, closing out this significant workstream. - **Update Payee Files:** The update to payee files was also confirmed as done, finalizing another scheduled deliverable. ## **Status Update on First Quarter (January) Deliverables** The bulk of the meeting focused on reviewing tasks slated for completion in January, with many items carrying over from December. The team assessed whether deadlines were still realistic, given the current date. - **General Timeline Assessment:** Most tasks were confirmed to be on track for their January or February deadlines as originally planned. - **Dependencies on External Partners:** Several specific items were identified as being dependent on external teams (Paikylady and Sign) for data, field definitions, or discrepancy resolutions. The completion of these items is pending feedback or action from these partners. - **Check Monitoring & Payment Data Reconciliation:** Active work is underway, but a final solution depends on an external team's response regarding a specific requirement. This item may slip into February. - **Electronic Payment Conversion & SLA Monitoring:** These are tied to reconciling payment data timing between systems. An analysis of discrepancies is in progress, with a call scheduled to align data refresh cycles and investigate missing records. - **Overall Q1 Outlook:** While there are external dependencies, the team plans to reassign completion dates by the following week. If external feedback is received imminently, tasks may stay in January; if delays are longer, they will be formally moved to February. ## **Planning and Discussion for February Initiatives** The discussion looked ahead to February's workload, which includes several multi-month initiatives concluding and new potential work items. - **Upcoming Major Deliverables:** Key items ending in February include the Data Validation System Status, UBM Credential Management, and the foundational work for the Arcadia integration. - **Evaluation of Potential Work Items:** Two items, "MFA Phones and Downloads," were highlighted for a strategic decision. Their necessity is contingent on the volume of accounts remaining in-house post-Arcadia integration, which is projected to be a small minority (max ~12%). The team agreed to analyze the specific subset of accounts affected before allocating resources, as the work involves implementing a workaround using personal phones. - **Resource Allocation:** The general sentiment was that the February plan is achievable, but final commitment to the MFA-related tasks is pending further data analysis. ## **Forward Look into March and Project Closing** The preview of March shows a lighter scheduled load, allowing for potential spillover from previous months. - **March Deliverables:** The primary items are the Integrity Checks (which may become unnecessary) and the Bank Poll feature. The Bank Poll work is noted as being primarily driven by an external partner with minimal internal effort required. - **External Partner Coordination:** For the Bank Poll, the team suggested initiating early conversations with the external partner to prepare for the upcoming work. - **Meeting Conclusion:** The session concluded with a reiteration of the shadowing participant's role and a plan to provide the discussed project timeline update to leadership.

## **Summary** ### **Understanding the GL Allocation Report and Mapping** The meeting began with a technical discussion of a General Ledger (GL) allocation report, which is used for SOX compliance to monitor changes in GL account coding. A core challenge was identified: the service type descriptions (like "Other Services" or "Miscellaneous Charges") provided by the current vendor are too generic and do not reliably map to specific GL codes. For instance, the "Other Services" category could contain deposits or other one-off charges, all posting to the same GL, while "Miscellaneous Charges" could post to two different GLs despite the identical description. - **The key resolution** was the agreement that a complete and precise mapping is required. Instead of the vague service types, the team will provide a filtered chart of accounts containing *only* the GL codes relevant to utility billing. This mapping will explicitly define what specific charge on a utility bill (e.g., deposit, water, sewer, late fee, repair) corresponds to each unique GL account number. This definitive mapping is a prerequisite for configuring the new platform correctly. ### **Methodology for Allocating Charges to GL Codes** The conversation detailed how charges on a bill are split across multiple GL accounts. For commodity charges like water or electric, allocations are based on a fixed percentage split tied to a specific utility account. These splits can differ by commodity on the same bill (e.g., electric and gas on one bill can have different allocation percentages). - **Hard-Coded Allocations:** Certain charge types, such as late fees and deposits, are consistently allocated 100% to a single, predefined GL account. This logic would be hard-coded in the new system. - **Miscellaneous & Tax Charges:** For non-standard or tax charges, the allocation defaults to mirroring the percentage split of the main commodity charges on that bill. - **Change Management:** These GL allocation splits are typically reviewed and potentially updated on an annual basis, though a new monthly billing process may lead to more frequent changes, which is under internal review. ### **Handling Complex "Summary" Utility Bills** A significant portion of the meeting was dedicated to addressing "summary" bills, where one utility account encompasses multiple properties or service addresses. The analysis covered two complex scenarios: a single-property bill with multiple commodities (electric, water, sewer) and a multi-property bill where different service addresses on one invoice correspond to different legal entities. - **Proposed Technical Solution:** The platform can handle these by treating each unique service address or commodity combination as an individual line item ("build block"). Each block can then have its own specific GL allocation applied. - **Data Field Consideration:** A key decision point was whether to use the original, overarching utility account number from the bill or to create a composite identifier. The tentative agreement is to use the original account number, with the understanding that a crosswalk will be provided to financial reporting to reconcile this with existing records on day one. ### **Payment File (TXT) Specification and Build** The team reviewed the technical specifications for the payment file that will be sent to the JD Edwards (JDE) system. The discussion confirmed and clarified several formatting rules for the fixed-width text file. - **Field Formatting:** Specifics included leaving certain character ranges blank, using a Julian date format, and left-padding the business unit field with spaces (not zeros) to ensure it is a 12-character string. - **GL Account Format:** The GL account will be passed as a single attribute string (e.g., `0115.501530.0000`) and then parsed into its constituent parts (business unit, object account, subsidiary) within the file generation logic. - **Vendor Name & Charge Scope:** The vendor name field will be populated with a customized "pretty name," truncated to 30 characters. Importantly, it was confirmed that the payment file should only include charges for the *current* service period; any past due amounts paid would create a discrepancy and require a separate process. - **Data Aggregation Logic:** For the billing dates on aggregated lines (where multiple charges roll up to one GL line), logic will need to handle potentially different service periods, though they are typically the same. ### **Prerequisites and Next Steps** The meeting concluded by identifying critical path items required to finalize the build. The single most important prerequisite is receiving the final, filtered GL code mapping from the accounting team. This mapping will unlock the configuration of allocation rules and the generation of the required SOX compliance report. The clarifications on summary bill handling and TXT file specifications have defined the development path forward, pending that key data input.

## Summary The discussion primarily focused on two major operational challenges: compliance requirements for SOC (System and Organization Controls) and significant project hurdles related to the "Simon" client implementation. Concerns were raised regarding a potential resource crunch, with key personnel being stretched across three concurrent major initiatives: an Azure migration (with an August target), a SOC 1 Type 2 renewal (due in September), and a new SOC 2 Type 1 audit. The approval and integration of the "Vanta" tool for compliance automation was also flagged as a lengthy bureaucratic process within the larger organization (Constellation). The bandwidth for managing extensive manual policy work alongside technical projects was a primary worry. The bulk of the conversation centered on the Simon project, where deep uncertainty about the timeline and feasibility was expressed. While initially aiming for a late March go-live, continuous discovery has revealed more complexity than anticipated. The core issue is replicating legacy system ("NG") functionality, specifically around generating custom financial reports and data files (like AP payment files). A critical blocker is the lack of clarity on GL (General Ledger) allocation requirements at a detailed charge-type level, which the current platform does not natively support. This fundamental mismatch could require heavy customization. The process is hindered by fragmented client knowledge, inefficient requirement-gathering meetings, and the absence of a single, empowered decision-maker on the client side. A key internal meeting was scheduled to reassess the Simon go-live date and strategize on communicating challenges externally. ## Wins - A critical blocker for the Simon project (GL allocation logic) was clearly identified as the central issue requiring immediate resolution, bringing focus to the core complexity. - Potential leverage points for pushing back on client demands were identified, such as challenging the necessity of certain year-end reports by April and potentially delaying non-essential reports. - Progress was made in understanding the true scope of customization needs for clients, distinguishing between essential AP file integrations and less common, fully customized reports. ## Issues - **Severe Resource Constraints:** A major bandwidth conflict exists for the core team between the Azure migration, SOC 1 Type 2 renewal, and the new SOC 2 audit. The Azure migration is likely to take priority, putting the SOC compliance timelines at risk. - **SOC Compliance Complexity:** There is confusion over audit scope (SOC 1 vs. SOC 2) and concern over the manual effort required for renewals. The approval process for the "Vanta" automation tool within the larger corporate structure is expected to be slow and could delay evidence collection. - **Simon Project Timeline at Risk:** The late-March go-live date is considered highly unrealistic. Requirement gathering is still incomplete and inefficient, with new reports (now five essential ones) still being discovered. - **Fundamental Product-Requirement Mismatch:** The client's need for GL allocations at the charge-type level may not be supported by the current product architecture, implying significant customization or a difficult conversation about scope. - **Inefficient Client Engagement:** Meetings with the Simon team are described as unproductive, with too many participants, no clear ownership, fragmented knowledge, and a resistance to recording, leading to repetitive discussions. - **Upcoming Absence:** A key team member will be absent for a full week, further slowing progress on the already-delayed Simon requirements phase. ## Commitments - **Faisal Alahmadi** to double-check the approval status of the "Vanta" tool within the larger organization (Constellation). - **Faisal Alahmadi** to pull and provide a list of vendors for the compliance team to review, aiding the SOC 2 process. - The team to use the scheduled internal meeting to formally reassess the Simon go-live date and develop a strategy for external communication regarding delays and challenges. - The team to raise the fundamental issue of GL allocation requirements during the internal meeting to determine a product and project strategy. - The team to revisit and discuss resource allocation and prioritization for the three major initiatives (Azure, SOC 1, SOC 2) in the following week.

## **Policies for SOC2 Compliance** The meeting began with a core discussion on sourcing the necessary policies for the SOC2 compliance framework. It was determined that existing policies are not housed in a dedicated "policies" section within Confluence; instead, relevant information is dispersed across various pages, requiring compilation. A strategic decision was made to use Constellation's existing policy set as a foundational template, with adaptations for the organization's current operational state, rather than building all policies entirely from scratch. - **Using Constellation's policies as a baseline:** This approach was chosen to ensure alignment with future integration plans and to avoid potential gaps or conflicts. The policies will be reviewed and adjusted to fit the current environment, particularly for areas like acceptable use and asset management. - **Addressing policy gaps:** It was noted that a data management policy covering data retention specifics may need to be created or augmented, as this is a SOC2 requirement not fully covered in the existing Constellation documentation. - **Flexibility for future changes:** The plan allows for policies to be updated later when the organization fully integrates into the Constellation infrastructure and onboarding processes, ensuring a smooth transition. ## **Timeline and Observation Period** The target timeline for the SOC2 Type 2 audit was a major point of discussion, directly influencing the policy strategy. The goal is to establish a quarterly observation period in Q3 (July to September), followed by the audit. - **Targeting a Q3 observation window:** Initiating the observation in Q3 sets the stage for the subsequent audit and allows the compliance framework to be tested during that period. - **Implications of the migration timeline:** A significant consideration is the planned migration from GCP to Azure. Since full integration with Constellation's Azure environment is expected post-Q3, the initial compliance efforts will focus on the current GCP setup, with policies tailored to present operations. - **Phased policy alignment:** The policy work will proceed based on the current operational model, with the understanding that they will be updated or replaced once the organization is operating within the Constellation Azure environment and adhering to their standard processes. ## **Access Control and Device Management** A detailed conversation addressed the practical challenges of access control and device management, especially concerning contractors and the current hybrid infrastructure setup. - **Contractor device compliance:** A potential challenge identified involves contractors, particularly those from Cognizant, using their own company-managed devices. The concern revolves around ensuring these devices meet security standards for password policies, screen lock, and antivirus, which may be outside direct control. - **Onboarding process verification:** It was confirmed that while contractors may not use Constellation-issued machines, there is a documented onboarding process via Cognizant and internal access approval tracking through Jira for application and tool access. This documented, approval-based process is considered sufficient for SOC2 controls. - **Current infrastructure scope:** The team clarified that most daily work is conducted outside the Constellation VPC, primarily within GCP, and does not currently leverage Constellation's endpoint detection and monitoring services like CrowdStrike Falcon. ## **Integrations and Automated Testing** The team explored the technical implementation of compliance monitoring through the Vanta platform, focusing on integrations for automated testing and evidence collection. - **Initial integration with GCP:** The immediate action is to connect the GCP environment to Vanta. This enables automated testing of configurations against SOC2 requirements, streamlining evidence collection compared to manual screenshots and documentation. - **Scoping integration for production:** The integration can be scoped specifically to the production environment within GCP, excluding test or development projects, which keeps the SOC2 audit focused on relevant systems. - **Future challenge with Azure integration:** A foreseen hurdle is integrating Vanta with the future Azure environment, as it will require approval from Constellation's infrastructure and cybersecurity teams due to their strict bureaucratic controls. A workaround using manual evidence collection is planned if automated integration is not permitted. - **Admin access for the team:** Key personnel were granted administrator access within Vanta to configure integrations, manage scopes, and address any failing automated tests. ## **Vendor Management and Risk Assessment** The final substantive topic covered the process for managing third-party vendor risk as part of the SOC2 compliance framework. - **Compiling the vendor inventory:** The first step is for the internal team to add all third-party vendors used in the service delivery (e.g., SendGrid for email) into the Vanta platform. - **Focus on high-risk vendor reviews:** Subsequent analysis will categorize vendors based on risk. Comprehensive security reviews will be prioritized for high-risk vendors, specifically those that have access to sensitive organizational data or pose a significant security threat. - **Clarification on data flow:** It was noted that many current vendors are service providers where data flows primarily *from* the vendor to the organization, not the other way around, which may influence their initial risk categorization.

## **Review of Current Development Tasks and Status** The meeting began with a systematic review of multiple development tickets to verify their completion status and deployment environment. This was done to clean up the task backlog and ensure alignment on what was ready for production versus what remained in testing. - **Operators Nodes and Soft Vendor Sorting:** Several features were confirmed as completed and deployed to the production environment. This includes the "FDD Connect Operators" nodes, the ability to sort vendors alphabetically by invoice count, and the display of the user who created a record. - **Pagination Fix and Build Template Features:** A bug related to pagination resetting when switching between vendors was confirmed as fixed. Updates to the build template, such as adding an "Updated On" field and linking invoice templates to specific build records, were reviewed. These features are currently available in the test environment but are **awaiting deployment to production**. - **BDE/Third-Party Flag and Activity History:** A flag to mark vendors enrolled with a third-party service (initially BDE, to be expanded for Arcadia) was implemented and is live. The Activity History feature, which tracks changes made to records, was demonstrated in the test environment and is also ready for production deployment pending final verification. ## **Credential Management System Development** A significant portion of the meeting was dedicated to reviewing the progress on a new Credential Management system, which is crucial for ensuring data consistency and preparing for third-party integrations. - **Core Validation and Management Pages:** Development is nearly complete on two key interfaces. The **Validation Page** identifies credential mismatches between systems (e.g., differing passwords) or credentials that exist in only one system, requiring manual review. The **Management Page** will automatically house credentials that perfectly match across systems. - **User Workflow and Filtering:** The user can resolve discrepancies on the Validation Page by selecting which system (UVM or DSS) should be considered the "source of truth." The interface includes client filters, allowing operators to focus on specific customers during cleanup. A proposal was made to add an "archive" action for obsolete accounts. - **Next Steps and Automation Logic:** The remaining work involves deploying the current changes to a test environment and refining the underlying automation logic. The system is designed to continuously compare credential tables and flag new discrepancies as they arise, preventing bulk mismatches in the future. The "matched records" filter on the Validation Page will be removed, as matching credentials will automatically move to the Management Page. ## **Cleanup of Problematic Builds and Data Integrity** A priority task involves cleaning up billing data that was incorrectly processed or is missing crucial client information, which is essential to prevent corrupted data from propagating to downstream systems. - **Identifying and Isolating Bad Data:** The focus is on scanning for and marking entire bills or individual line items that have missing or incorrect Client IDs. These problematic records are being flagged for deletion. - **Operational Review and Communication:** A detailed Excel report is being generated that lists all affected client accounts and bill IDs. This report will be shared with the operations team for their review and final confirmation before any deletion occurs, ensuring no accurate data is accidentally removed. ## **Planning for Arcadia Integration and Foundation** The team discussed the strategic approach for integrating with a new third-party service, Arcadia, balancing immediate client needs with building a sustainable, long-term solution. - **Immediate "One-Time" Effort for Ascension:** For the initial client (Ascension), a short-term, manual process will be established. This involves periodically calling Arcadia's API to pull statement PDFs and then ingesting them into the system. The goal is to service this client quickly while the foundational infrastructure is built. - **Designing the Long-Term Foundation:** The sustainable solution involves setting up a **webhook listener** to receive notifications from Arcadia when new statements are available. The service would then automatically fetch the PDF, extract the client account number, and match it to existing internal client-vendor data before ingestion. - **Key Technical Challenge - Client Matching:** A central discussion point was the complexity of reliably matching incoming Arcadia statements to the correct internal client and vendor combination. Relying solely on the account number in the PDF was deemed potentially too simplistic. A more robust matching logic, possibly leveraging the new credential management tables, is required to ensure accuracy and avoid future issues. ## **Prioritization and Forward-Looking Roadmap** The conversation concluded with setting clear priorities and defining the next steps for each team member to move the key initiatives forward effectively. - **Finalizing Credential Management:** The immediate next step is to deploy the credential validation and management pages to a test environment for final review and testing. - **Technical Design for Arcadia:** Following the completion of the data cleanup, a dedicated technical assessment and design document for the Arcadia integration foundation will be created. This will break down the required tasks, such as building the webhook listener, the client-vendor matching service, and the automated ingestion pipeline. - **Task Ownership and Epic Alignment:** Work will be organized into clear epics. The credential management work will support the broader Arcadia integration. The reports feature and specific Arcadia-related development tasks will be assigned to the appropriate team members for parallel progress.

## Summary The meeting focused on diagnosing significant data processing errors, outlining immediate corrective actions, and planning architectural improvements to prevent future issues. A central theme was the critical breakdown in the process of matching and ingesting customer billing data from a vendor (Arcadia) into the internal system (DSS), which led to incorrect client-vendor mappings being pushed forward. ### Root Cause Analysis of Data Errors The core of the discussion involved dissecting how incorrect data was processed and identifying three distinct categories of errors. These issues stemmed from a manual, multi-step process vulnerable to miscommunication and a lack of automated validation. - **Incorrect Client-Vendor Matching:** This was the primary issue, where the system or process incorrectly associated a bill from one vendor with a different client. This occurred despite having a known set of credentials, suggesting a flaw in the matching logic or its manual execution. - **Missing Client IDs:** A subset of records was processed with completely blank client identification fields. The cause was unclear, but it pointed to a failure in the initial data extraction or naming convention, allowing files without proper identifiers to enter the workflow without being flagged. - **Multi-Account Bill Complications:** Some files contained data for multiple customer accounts bundled together, which the existing process was not designed to handle correctly. While this was a large batch, it was noted that these errors were caught before payment processing. ### Strategic Process Improvements and Automation To address these failures, the conversation shifted to designing a more robust, automated system. The goal is to move away from error-prone manual steps and implement controls that ensure data integrity from the point of collection. - **Enforcing Automated Validation:** The future state requires that the Client ID and Vendor ID pairing be automated and mandatory based on the credential set. The system must reject or flag any file where this pairing is missing or doesn't align with the credential permissions, preventing incorrect matches from the start. - **Implementing Comprehensive Logging:** A new logging table is needed to create a complete audit trail. This would track every API call to Arcadia, link the downloaded files (PDFs and JSON) to specific credentials and triggers, and record their storage path. This transparency would drastically reduce the time needed to diagnose problems. - **Centralizing and Hosting Key Components:** The current locally-run scripts must be moved to a cloud-hosted environment. Alongside this, a centralized, approved cloud storage directory (e.g., on Azure) is required for all downloaded files before DSS ingestion, replacing the unreliable manual upload process. ### Team Capabilities and Architectural Leadership A significant portion of the meeting was dedicated to evaluating the team's capacity to design and implement these complex systemic changes, revealing a strategic gap in senior technical leadership. - **Identifying a Solutions Architecture Gap:** While the current development team is competent on implementation, there is a recognized lack of a dedicated resource to own high-level technical architecture. This role is needed to holistically understand the product, evaluate different solution paths (like migrating functions from DDS to DSS), and make strategic design decisions without deep immersion in day-to-day coding. - **Exploring Resources to Fill the Gap:** Options were discussed to bring in an external solutions architect, possibly from an existing partner like Cognizant or Canvascraft. The priority is finding someone who can quickly understand the business context, take ownership of major technical milestones, and guide the team through the upcoming wave of changes focused on DSS optimization and migration projects. ### Technical Infrastructure and Access Practical next steps were outlined concerning the technical environment needed to support the new process and enable more efficient work. - **Selecting Approved Cloud Storage:** Due to organizational cybersecurity policies, the storage solution for the PDFs must be on an already-approved platform, specifically legacy GCP or the organization's Azure instance. Azure was highlighted as the preferred contender due to existing integrations and the ability for the team to configure it quickly. - **Enabling Development Access:** A secondary need was identified for a Windows-based virtual machine to allow for direct editing and troubleshooting of certain reports and tools that require a Windows environment, which would improve operational efficiency for key personnel.

## Customer The customer operates in the energy or utility management sector, utilizing the platform for processing and validating a high volume of invoices and meter data. Their role involves managing complex billing data across multiple systems and ensuring accuracy for various client accounts. The background indicates a transition from legacy processes to a more automated platform, though this shift has involved integrating historically inconsistent or "janky" data, creating a unique set of challenges for this specific client compared to others. ## Success The most significant achievement has been the establishment of an automated build validation system. This dedicated framework allows for the continuous monitoring and flagging of data discrepancies. It represents a foundational step toward systematic data cleanup and provides a structured method to identify errors, such as invoices posted to incorrect client accounts or unit of measure issues, which were previously more difficult to isolate at scale. ## Challenge The primary and most persistent challenge is the misapplication of invoice data to the wrong client accounts within the system. This core data integrity issue leads to cascading problems, including incorrect payments and significant manual rework. The root cause appears to be a disconnect between source systems pulling correct account numbers and the platform applying them incorrectly, indicating a need for a more robust matching or flagging mechanism within the workflow. This issue is compounded when processing large, automated data drops from integrated systems, which can introduce hundreds of errors before they are caught. ## Goals Key objectives for the customer moving forward include: - Achieving complete and accurate data synchronization to eliminate invoices being placed on the wrong accounts. - Successfully cleaning up historical data for specific, complex clients as a pilot, with the expectation that subsequent client data migrations will be smoother. - Implementing a long-term, scalable solution that reduces reliance on manual band-aid fixes and constant firefighting. - Gaining clearer, more reliable reporting and visibility into processing statuses and backlogs to better manage operations and customer expectations. - Developing a controlled, efficient method to reprocess or correct batches of invoices when systemic errors are identified, without enabling uncontrolled system access.

## Summary The meeting focused on several ongoing technical challenges, primarily centered around data tracking issues in payment file generation, and provided updates on current development sprints. Discussions covered immediate workarounds, future architectural solutions, and progress on automated testing infrastructure. ### Payment File Generation and Data Tracking Issues A significant data gap exists in matching generated payment files to specific bills, which complicates reconciliation and user downloads. - **Current System Limitation:** The core issue is that the system does not store the actual file names at the individual bill level in the database. Currently, data is aggregated and presented at the day level. This makes it impossible to definitively know which bills were included in a specific AP (Accounts Payable) or MUC file, especially when multiple files are generated or regenerated on the same day. - **User Experience Impact:** Because files cannot be matched precisely, the current workaround is to present users with *all* files generated for a customer on a given day when they click the download button. Users must then manually inspect these files to find the correct one, which is inefficient. - **Future Solution with Payment Refactoring:** A comprehensive fix is tied to the ongoing payment refactoring project. Once deployed, the new architecture will store the file name and batch ID at the bill level, enabling precise grouping. This will allow the system to display and offer for download a single, correct file corresponding to each batch. ### Current Development Work and Sprint Updates Team members provided brief overviews of their recent and ongoing development work across various functional areas. - **Virtual Account and Bulk Features:** Work was completed on fixing bugs related to virtual account functionality and implementing the backend processing for bulk operations on feature accounts, complementing previously built front-end download components. - **Summary Items and Refactoring:** Progress was made on refactoring summary items logic to include data based on customer preferences, such as pasture mode and pass-through amounts. This work was decoupled from a larger effort to expedite its delivery. - **Payments Area and Reporting Support:** Efforts in the payments area included fixing bugs related to the ongoing refactoring and implementing support for Excel files required for specific reports (Simon reports). These issues have been resolved. - **Upcoming AP File Logic Update:** A separate, urgent update to the AP file generation logic for a specific client (Jcode) was discussed. This update, which involves adding a new column and modifying line items, is **not dependent** on the broader payment refactoring release and can be deployed independently on its own timeline. ### Automated Testing Infrastructure Setup Foundational work has been completed to integrate automated testing into the development pipeline, establishing a base for future improvements. - **Initial Implementation:** Automated test suites have been set up to run on a scheduled basis in the demo environment. While some tests are currently failing-which was anticipated-the infrastructure for execution and reporting (including screenshots and videos for failures) is now in place. - **CI/CD Integration:** A key milestone is the integration of a trigger that allows these automated tests to run directly when a comment is posted on a Pull Request (PR). This marks a significant first step toward continuous integration, with clear pathways for future enhancement, such as triggering tests on PR creation or merge. ### Bug Fix for User Data Retrieval A specific performance bug was identified and resolved, relating to a third-party service limitation. - **Root Cause and Solution:** The "Users" page would error when loading 100 users at once because the underlying service (Auth0) has a hard limit of retrieving 50 user records per request. The fix involved implementing pagination on the front-end query, splitting the request into two sequential calls of 50 users each to work within the external constraint.

SOC 2 readiness review ahead of the March 15 Type II audit. Identified access control gaps and logging coverage issues. Clear ownership assigned — Alex on infrastructure remediation, Priya on documentation. On track if remediation completes by Feb 15.

## Summary The meeting centered on critical dependencies and timeline challenges for a client implementation project. Key discussions revolved around the execution of a Letter of Authorization (LOA), the confirmation of report specifications, and the cascading impact these have on the overall project go-live date. ### Letter of Authorization (LOA) Execution and Dependencies The execution and delivery of the LOA to the client is a major bottleneck, with a hard internal deadline identified. - **LOA Status and Deadline:** The LOA is ready for final sign-off but must be sent to the client by **February 5th** to trigger a 60-day setup period for EDI bills. However, a conflicting internal requirement insists that all "day one" reports must be fully tested and ready before the LOA is sent, creating a significant scheduling conflict. - **Client Readiness as a Constraint:** There is strong skepticism about sending the LOA on time because the client is internally disorganized. They have not provided complete specifications and have introduced new, previously uncommunicated requirements, making the team hesitant to start the formal EDI setup clock. ### Report Requirements and Scope Confirmation Major delays are expected due to incomplete and expanding client requirements for the custom reports needed for go-live. - **Newly Discovered Requirements:** During a recent call, the client introduced two major new requirements: the need for reports to integrate with **Anaplan** (in addition to the known JD Edwards system) and a completely new **"Vendor Details" report** that had never been formally communicated, though a related file was discovered in a shared drive from months prior. - **Scope Confirmation Timeline:** The team is far from confirming the full scope. While the AP file report is relatively close to finalization, the numerous outstanding questions and new reports mean scope confirmation is realistically **at least 30 days away**. The team lacks sufficient information to provide reliable timelines for the custom reports. ### Project Timeline and Go-Late Impact The interdependencies between the LOA, report specifications, and development work will substantially delay the project's completion. - **Dependency Chain:** The project timeline is driven by a critical path where **report scope must be confirmed** before the **LOA can be sent**, which must then be followed by the **60-day EDI setup period**. Delays in confirming scope directly push out the go-live date. - **Unrealistic Client Expectations:** The client's expectation to have all reports, including one not needed until late 2026, completed for "day one" was challenged as illogical and a primary contributor to the timeline extension. The team is aligned on pushing back on this demand. ### Strategic Adjustments and Planning The discussion focused on adapting the project plan to reflect the new reality of extended timelines and unclear requirements. - **Restructuring the Plan:** It was suggested that the "Scope Confirmed" milestone be broken down **per report** rather than being a single project milestone, accurately reflecting the piecemeal nature of receiving client requirements. - **Re-baseliding Expectations:** The team acknowledged the need to provide the client with a new, later go-live date, as the current date is unachievable. All tentative dates for custom reports are considered placeholders until firm specifications are received from the client.

Navigator platform sync to align on Q1 roadmap. Key decision to prioritize offline mode over widgets in v2.4. QA automation push targets 90% coverage. Cross-team dependency mapping created for Arcadia integration timeline.

## Summary This technical meeting focused on clarifying how line items from utility bills are processed and mapped within a billing platform's payment and accounting systems. The discussion centered on understanding the granularity required for payment files and the corresponding general ledger (GL) account mapping. ### Understanding Bill Composition and "Bill Blocks" The analysis of an example water and sewer bill revealed that individual charges are represented internally as distinct "bill blocks." A key question emerged about whether related charges for a single commodity should be consolidated or kept separate in downstream files. While a water bill showed separate blocks for water and sewer charges, an electric bill example demonstrated that a single commodity (electricity) could still be split into multiple bill blocks, such as for distribution and supply portions. ### Determining the Payment File Structure A primary goal was to resolve how these bill blocks translate into rows within the payment file sent to financial systems. Based on initial review, the indication is that each line item or bill block typically results in a separate row in the payment file, rather than rows being consolidated by commodity. This is further evidenced by the handling of ancillary charges like late fees and miscellaneous charges, which also appear as their own discrete rows. ### General Ledger Mapping Complexities The conversation highlighted that the need for separate payment file rows is often driven by accounting requirements. A single customer bill may need to be distributed across multiple General Ledger (GL) accounts (e.g., separate accounts for late fees, deposits, taxes, or different service components). This GL-driven breakdown is a critical factor determining the final structure of the payment data, as each unique GL code generally necessitates its own line item. ### Clarifying Account Codes vs. GL Codes During the discussion, a distinction was made between different code types present in the data. It was clarified that "account" codes visible in the bill file likely refer to customer or service accounts, not to GL accounts. The crucial mapping for accounting purposes is between the type of charge (e.g., "late charge," "deposit") and its corresponding GL account code, which is maintained in a separate mapping table or logic. ### Requirements for Accurate Data Mapping To ensure correct financial posting, a clear and detailed mapping logic is required. This logic must define the specific GL account code to be used for every possible type of charge or bill block (commodity, late fee, deposit, tax, etc.). Establishing this mapping is essential for automating the generation of accurate payment files that correctly reflect how payments should be allocated within the general ledger.

## Summary ### Introduction to the DSS Audit Queue Feature A new feature called the DSS Audit Queue has been implemented within the DSS application to address a critical gap in the automated billing process. The primary purpose is to intercept bills generated by the Large Language Model (LLM) that are missing essential information deemed necessary for processing. Instead of allowing these builds to fail completely at the output service level, they are now routed to a dedicated queue for manual review by a DS operator, ensuring problematic builds are caught and corrected before finalization. ### Filtering and Monitoring Builds in the Queue The feature introduces a dedicated "Build Validation" screen that intelligently filters and displays builds requiring attention. The system isolates builds based on a specific "DSS AutoQ" status and a "Process" build status, indicating they are pending review and have not yet been processed by the DDIS system. This provides operators with a real-time, centralized view of all builds awaiting manual intervention, complete with a counter on the application's side panel for immediate awareness of backlog volume, such as the nearly 890 builds noted during the demonstration. ### The Manual Review and Update Process Operators can review each queued build and manually correct the identified errors. The interface is designed for efficiency, automatically highlighting the specific row within a build that contains an error to direct the reviewer's attention. Corrections are made directly within this interface, and changes are saved automatically upon update. For additional context, reviewers can access the original PDF document associated with the build. Once a build is corrected and closed, it is removed from the queue and can proceed through the system. ### Common Error Examples and Resolution Workflow The demonstration highlighted several common error types that land builds in the audit queue, providing insight into typical failure points. A frequent issue is the system's failure to identify the **client ID**, which is a fundamental piece of information required for processing. Another example shown was an **invalid service item description**, where the extracted text (e.g., "Generation off peak UCP off") did not match expected values or formats. The resolution involves the operator reviewing the highlighted error, determining the correct value (such as updating a "Thermal" unit of measure to the proper term), and inputting it to allow the build to proceed. ### Integration Notes and Feedback Solicitation While the DSS Audit Queue streamlines validation within the new system, there are important limitations regarding integration with the legacy DDIS system. Any data filled out during the manual review in the DSS app **will not automatically carry over** to the legacy system; if further action is required there, it must be done manually. The feature includes a notes section for internal commentary. The development team is actively seeking feedback on the new workflow to identify any unforeseen friction points and improve the operator experience.

## **Summary** The meeting primarily focused on diagnosing and resolving critical issues within the billing output service, specifically concerning a large backlog of bills stuck in a "ready to send" state and a problematic retry loop for failed batches. A key theme was the need to balance immediate fixes to clear the backlog with planning for a more sustainable long-term solution. Effective communication and clarification of the exact problems being observed by the operations team were also highlighted as necessary next steps. ## **Root Cause Analysis and Current Issues** The discussion centered on identifying why a significant number of bills were failing to be sent to UBM and why failed batches were causing system congestion. - **The Primary Suspected Cause**: The root of the immediate service outage for components like the directory watcher and "laser" services was traced back to an expired client secret, a problem that was recently rectified. This suggests a systemic issue with credential management. - **The Retry Loop Problem**: A critical flaw in the current system logic was confirmed: when an individual bill or batch fails during output, the system immediately and continuously retries it. This creates a processing loop that blocks the queue, as many failures require manual intervention and cannot be resolved automatically through retries. - **Investigation into "Blank" Bill Errors**: There is a separate but parallel investigation into why some bills appear with blank or zero values in the interface. Initial checks on one example bill showed correct data, indicating the issue might be a display bug or a misinterpretation of the data, rather than a data integrity problem at the source. ## **Backlog Composition and Prioritization Concerns** A significant portion of the meeting was dedicated to understanding the scale of the backlog and establishing rules for processing order to minimize business impact. - **Scale of the Backlog**: Estimates of the backlog varied, but consensus settled on approximately 1,000 bills in the "ready to send" queue for auto-output, with an additional number needing manual review. All items currently in this queue appear to have validation issues preventing automatic processing. - **Urgent Need for Prepay Bills**: A clear business priority was established: prepaid customer bills must be processed and sent to UBM ahead of historical or postpaid bills. There is a pressing backlog of 500-600 prepay bills for key customers that are currently delayed. - **Lack of Built-in Priority**: The existing output service operates on a simple first-in, first-out basis with no mechanism to prioritize prepay bills or deprioritize repeatedly failing items, which contributes to the current congestion. ## **Current System Status and Operational Impact** The team assessed the real-time state of the output service to determine immediate next actions. - **Output Service Currently Idle**: Following the credential fix, the output service has cleared its previous massive internal queue and is now in a state where it is not processing anything. This is because all bills currently marked "ready to send" are flagged with errors. - **Implication for Manual Efforts**: This status means that any bill needing correction requires a manual update by the operations team before it can be successfully processed by the automated system. The system will not proceed until these validation issues are resolved. - **Communication Gap on Symptoms**: There is confusion regarding the exact symptoms the operations team (Afton and Rachel) are experiencing. Reports of continuous reprocessing and missing error logs need to be clarified to confirm if they are seeing the retry loop issue or a different problem entirely. ## **Proposed Solutions and Implementation Trade-offs** Two potential solution paths were discussed, each with different timelines and levels of effort. - **Long-term Architectural Fix (Recommended)**: The favored solution is to modify the system's logic to move failed bills or batches out of the main "ready to send" queue and into a dedicated "failed output" queue. This would immediately halt the retry loop, allow for manual investigation, and prevent failed items from blocking the processing of other valid bills. - **Short-term Mitigation**: An alternative, simpler fix would be to implement a configurable delay (e.g., 24 hours) before the system retries a failed item. While faster to implement, this is seen as less robust than the dedicated queue approach. - **The Rollback Question**: The operations team has requested a rollback of the recent output service update. However, analysis indicates the update (changing from batch to individual bill processing) did not introduce the core retry logic flaw-the flaw existed in the previous version as well. A rollback is therefore viewed as unlikely to resolve the fundamental issue and may only provide a perceived change. ## **Immediate Next Steps and Coordination** The meeting concluded with a plan to gain clarity and unblock the highest-priority bills. - **Synchronize with Operations**: The immediate next action is to connect directly with the operations lead (Afton) to precisely define the issues she is observing, prioritize the list of problems, and ensure everyone is aligned on what needs to be fixed first. - **Test Manual Processing**: Now that the output service queue is clear, the operations team should test manually pushing corrected bills, particularly prepay bills, to verify that the basic send functionality is working and that they receive timely error logs. - **Focus on Prepay Backlog**: Concurrently, efforts should be focused on manually correcting and pushing the backlog of 500-600 prepaid customer bills as the highest business priority.

## Summary ### Output System Update and Immediate Backlog Crisis A recent update to the system's output functionality has led to a critical processing bottleneck, where batches are taking hours to send instead of seconds. The core problem is that the output process is continuously and unsuccessfully trying to send thousands of bills with existing data errors, which blocks the manual output of high-priority transactions. This situation has created significant operational delays, particularly for urgent bill pay customers. ### Scale of the Backlog and its Operational Impact The current backlog in the "ready to send" queue is substantial, containing over **3,067** bills. This backlog is not limited to new transactions but includes a large volume of historical, postpaid, and project makeup bills that have been failing repeatedly. The overwhelming number of failing items makes it impossible to distinguish between bills that are merely queued and those that have genuine errors requiring manual intervention, severely hampering the team's ability to prioritize and process time-sensitive work. ### Root Cause: Proliferation of Data Errors The primary driver of the system blockage is a large accumulation of unresolved data errors on individual bills. Common issues include missing invoice dates, invalid service dates, incorrect data in charge lines, and forms populated with inactive meter information. Because the output process retries these failed bills incessantly, it creates a continuous loop that consumes system resources and prevents clear bills from being processed efficiently. ### Proposed Short-Term Solution: Implementing a Delay Buffer To immediately alleviate the pressure and clear the functional transactions from the queue, a **24-hour delay buffer for retries** was proposed. This solution would instruct the system to wait a full day before re-attempting to send a bill that has failed, allowing all error-free bills in the queue to be sent first. This approach would dramatically reduce the backlog volume in the "ready to send" state, isolating the bills with genuine errors for manual review and correction by the operations team. ### Next Steps and Coordination The immediate action plan involves coordinating with the developer to assess the fastest path to resolution, whether that is implementing the proposed 24-hour buffer or temporarily rolling back the recent update. The goal is to implement a fix that decouples the processing of valid bills from the error-correction cycle, restoring the team's ability to manually output priority batches and begin systematically addressing the root cause data issues.

## Summary The meeting focused on reviewing the status of recent system updates, troubleshooting several ongoing technical issues, and outlining immediate next steps for development and operational tasks. Discussions ranged from specific service failures to plans for architectural improvements and cross-team coordination. ### Recent System Updates and Deployment Status The team reviewed the results of a recent deployment and the current operational health of various services. The overall update was largely successful, with most services and virtual machines now running on the latest versions. A specific update was deployed for the Output Service, which included the significant removal of a dependency on the Lock Manager service. This change has important implications for future maintenance and automation efforts. ### Critical Issues and Troubleshooting Multiple high-priority technical issues requiring immediate investigation were identified and assigned. - **Directory Watcher Service Credential Error:** This service is experiencing a credential failure. Investigation revealed two secrets in the VM2 environment variables, but their origin within the codebase is currently unclear. The immediate plan is to examine the service's source code and refactor it to align with the credential management patterns used by other applications. - **Output Service Data Discrepancies:** Following its update, reports emerged of issues with specific bills. Initial log analysis suggests the problems may stem from invalid service dates, but this requires verification with specific bill IDs. A separate, potentially more complex issue involves bills apparently stuck in a system (DSS) for five days, where related data (bill line items, services) exists but the UI displays a zero or red bid count with blank active meters, necessitating deeper database investigation. - **Build Validation Problem:** A separate issue with build validation was confirmed to be a known problem with a planned fix. The resolution involves applying a cherry-picked fix from lower environments directly to production as a hotfix. ### Pipeline Automation and Architectural Refactoring Plans were set in motion to improve operational automation and untangle a legacy codebase. - **Output Service Restart Pipeline:** A simple automation pipeline to restart the Output Service will be created in Azure DevOps. With its dependency on the Lock Manager now removed, the service can be restarted independently, making this pipeline straightforward to implement. Testing will proceed with caution to ensure no other services are impacted. - **Repository Consolidation:** A longer-term architectural goal is to break out individual services from the monolithic "PDAS" repository in Azure DevOps into their own dedicated repositories. This is acknowledged as a significant challenge due to intricate, legacy inter-dependencies between libraries and applications within the current structure, described as a "spaghetti monster nightmare." ### External Service Integration and Support Progress on integrating with an external service, Arcadia, was discussed, highlighting a need for clearer external communication. - **Arcadia Service Implementation:** Development of the service for Arcadia is reportedly underway and "working one way." However, several specific questions regarding the integration's behavior remain, particularly about the conditions that trigger webhook notifications (e.g., new statement creation vs. account addition). To resolve these, a direct thread will be initiated with the external technical support contact to seek clarification. ### Operational and Administrative Coordination The meeting also covered routine operational procedures and an administrative hurdle. - **Credential Synchronization:** The regular process of syncing credentials between DS and UBM systems occurs at least weekly, sometimes daily. To improve team-wide visibility, it was agreed that notifications for each sync will be posted in a dedicated Slack channel, moving away from direct messages to a single individual. - **Infrastructure Access:** A team member encountered a blocked access issue due to an internal IP change enforced by Zscaler, a corporate tool. The resolution path involves contacting the relevant infrastructure team (BDE) to obtain a new IP whitelist for the big data image, with management standing by to assist if delays occur.

## Summary The meeting focused on operational updates, primarily concerning data cleanup in a system referred to as "DSS" and significant progress with the Arcadia platform. Key topics included the cleanup efforts, managing customer credentials with Arcadia, the development of internal reporting tools, and strategic discussions around the necessary documentation for transitioning customer management. ### Progress in DSS Cleanup **Significant cleanup was completed over the weekend, making the process more manageable.** The effort involved archiving outdated or irrelevant customer data to streamline the system and prevent unnecessary processing. The cleanup process was noted to be intuitive, especially when cross-referencing with another system (UVM) to resolve uncertainties, highlighting an efficient method for maintaining data hygiene. ### Arcadia Customer Updates **Progress is being made with Arcadia, including successful credential matching for several customers and systematic tracking of outstanding issues.** A new internal reporting system is being developed to track all credential requests and filter them by customer, mirroring but improving upon the Arcadia dashboard's functionality. However, challenges remain with matching certain municipal co-ops due to ambiguous information, requiring collaborative trial and error with the Arcadia team to resolve. ### Credential Management System **A priority is to establish a clear system to manage the transfer and version control of customer credentials to Arcadia.** The goal is to avoid sending outdated credential files repeatedly by implementing a live report that automatically removes customers once matches are confirmed. A critical pending decision is selecting the initial set of credentials to officially hand over to Arcadia for management, pending further internal alignment. ### LOA Challenges and Process **The Letter of Authorization (LOA) is identified as a critical blocker for Arcadia to begin full production management of customer accounts.** There is a recognition that while onboarding data can be shared, the LOA is a prerequisite for Arcadia to proceed effectively. Historically, some customers have been hesitant to provide LOAs immediately due to concerns about premature account changes, indicating a need for careful customer communication and timing. ### Onboarding Documentation Review **A review of the customer onboarding document is necessary to determine what information can be proactively shared with Arcadia.** The team acknowledges they should assess the onboarding documentation to understand exactly what data they possess and can provide to Arcadia in the absence of a signed LOA, aiming to advance the process as much as possible with the available information.

Personal weekly planning session. Set gym schedule, deep work blocks, and reading goals. Low complexity but important for routine maintenance.

Weekly family call covering health updates, upcoming March visit planning, and home renovation timeline. Personal call with minimal work relevance.

January all-hands for the Constellation org. Celebrated strong January metrics (47 PRs, 99.7% uptime). Announced Arcadia integration as Q1 priority. Addressed on-call burnout with rotation changes. Engineering blog launching in February.

## Credential Management and Data Integration Challenges The discussion centered on significant operational hurdles related to credential management and data flow from Arcadia. A primary challenge involves manually managing thousands of customer credentials, many of which have issues preventing automated processing. The current strategy is a large-scale migration of all credentials to the Arcadia platform to consolidate and manage them more effectively, even though this reveals a high volume of problematic credentials that will require contractor support to resolve. A parallel effort is underway to develop a robust, internal credential management system to eliminate future manual tracking. Ensuring the quality and accuracy of data imported from Arcadia is also critical, with concerns about handling duplicate records, correct vendor and account tagging, and managing documents where key data points like statement dates are missing. - **Large-Scale Credential Migration to Arcadia:** All existing credentials are being loaded into Arcadia to centralize management, but this process has exposed that a significant portion have underlying issues that cause processing failures. - **Developing an Internal Credential Management System:** A long-term solution is to build a dedicated system for credential management to prevent reliance on manual spreadsheets and tracking, moving towards an automated, sustainable process. - **Quality Assurance for Incoming Arcadia Data:** The integration must carefully handle potential data problems, including de-duplication, ensuring vendor/account mapping is correct, and establishing rules for processing documents with incomplete information to avoid missing valid bills. ## Technical Hurdles and Solution Implementation Several specific technical blockers were identified that are impeding progress. A key issue was the use of an incorrect database table for vendor comparisons, which was creating discrepancies in data validation. The team resolved to switch to the correct `provider vendor` table. Furthermore, the implementation timeline for credential management updates has been delayed, partly due to a prior IP whitelisting requirement and the need to correct the vendor table logic, pushing the target completion to mid-next week. - **Correcting Vendor Data Source:** A critical bug was identified where the system was referencing a general `vendor` table instead of the more specific `provider vendor` table, leading to inaccurate data matching that must be corrected. - **Adjusted Timeline for Credential Updates:** Due to the vendor table issue and the team's schedule, the updates to the credential management workflow are now targeted for completion in the middle of the following week, allowing time for proper implementation and testing. ## Process Transition from DDS to DSS A major strategic shift involves moving key operational processes from the legacy DDS system to the newer DSS platform. The immediate focus is on transitioning bill editing and reprocessing functionalities. However, it's acknowledged that other critical tasks, such as initial customer and account setup ("summary builds"), will also need to be migrated. The transition is expected to reveal shortcomings in DSS's current capabilities that are not apparent until the system is under heavy operational use, necessitating further development. - **Prioritizing Core Function Migration:** The initial phase of the transition focuses on moving essential day-to-day tasks like editing and reprocessing bills into DSS to streamline operations and reduce dependency on the old system. - **Anticipating System Gaps Under Load:** It is expected that moving high-volume tasks to DSS will uncover functional limitations in its user interface and editing tools, requiring subsequent development sprints to address these gaps. - **Long-Term Roadmap for Full Transition:** Beyond immediate edits, the complete migration plan includes moving customer/vendor/account setup workflows and the final output service, which is currently a manual and brittle process within DSS. ## Onboarding Automation and Customer Self-Service Vision The conversation highlighted a critical strategic need to overhaul the customer onboarding process and move toward greater customer self-service. The current onboarding workflow is highly manual, relying on CSMs to interpret spreadsheets and manually enter data into DDS, which creates delays and potential for error. A future-state vision was outlined where onboarding and account management tasks could be initiated directly by customers or CSMs through a unified interface (potentially within UBM), creating a structured, auditable workflow that feeds directly into operational systems, thereby drastically reducing manual intervention and miscommunication. - **Eliminating Manual Onboarding Friction:** The goal is to replace error-prone manual data entry from spreadsheets with a structured UI that captures customer, vendor, and account setup information cleanly at the point of entry. - **Creating a Unified Workflow Interface:** The vision is for a single system where tasks like new account setup, bill submission, and service cancellation can be initiated, creating a trackable workflow instead of relying on unstructured email chains and manual handoffs. - **Reducing CSM Dependency for Simple Tasks:** Automating these processes is essential for scaling, as it frees CSM time from administrative tasks and prepares the platform for serving mid-market or self-serve customers who cannot rely on high-touch manual support. ## Operational Gaps and Manual Workflow Crisis A significant operational risk was surfaced regarding the complete lack of automation for handling customer-submitted documents. Currently, customers email bills and requests to a shared inbox, which requires manual monitoring and processing by team members who are already overloaded. This has led to requests being lost or severely delayed, damaging customer trust. Automating the ingestion and routing of these email submissions is now recognized as an urgent priority to prevent failures and improve reliability. - **Critical Breakdown in Email Processing:** Customer communications sent to a generic inbox are not being processed in a timely or reliable manner because the task is manual and low priority for overwhelmed staff, leading to lost requests and customer frustration. - **Urgent Need for Ingestion Automation:** The immediate solution is to implement an automated system that processes incoming customer emails, extracts attachments, and routes them into the correct processing queues without manual intervention, ensuring no request falls through the cracks. ## Planning for Structured Operational Updates To improve visibility and coordination across multiple ongoing projects (Arcadia integration, credential cleanup, DDS transition, automation work), the team agreed to establish a formal structure for weekly update meetings. The goal is to move away from ad-hoc discussions and instead provide consistent, trackable updates on each major initiative. This will help align the development team, operations staff, and management, and reduce the time spent clarifying the status of completed or irrelevant issues. - **Establishing a Consistent Reporting Rhythm:** The team will implement a weekly update meeting with a standardized format to review progress across all active development and operational projects. - **Improving Cross-Team Visibility:** A structured update, potentially using a shared slide or table, will help keep all stakeholders informed on priorities like Arcadia metrics, credential cleanup status, and key ticket resolutions, minimizing misalignment and repetitive questions.

## Missing Bills and Final Bill Identification The meeting opened with a critical operational issue regarding the identification and processing of "final bills" in the invoicing system. A key problem was that when a vendor submits a final bill, it is not always being properly flagged and closed within the system, causing ongoing accruals for accounts that should be closed. The primary reasons were twofold: the system requires a specific field to be marked or a button to be clicked, and not all vendors explicitly label their invoices as "final bill." - **Systematic identification challenges:** While utility distribution bills often state "final bill," supply-only bills (e.g., from Constellation) typically do not. This makes automated detection difficult. - **Proposed solution with AI:** To address this, a plan was formed to train a Large Language Model (LLM) to automatically identify final bills. The model will be trained on examples, looking both for explicit text and contextual clues like unusually short service periods. - **Immediate action:** A specific error code (3034) in the system will be used as a source for examples to train the AI model, aiming to integrate this validation into the upcoming DSS application. ## Virtual Account Cleanup Efforts Significant time was devoted to ongoing cleanup efforts for misaligned or "virtual" accounts across different systems. A substantial backlog has developed, with about 20 customer requests pending, a number that grew during a recent industry conference. - **Prioritized customer list:** Cleanup is proceeding on a customer-by-customer basis using a priority list. Initial work has been completed for specific clients like St. Elizabeth and Munson. - **Manual alignment process:** The current method involves exporting data from different systems and manually aligning account numbers, which is time-consuming. A suggestion was made to improve future alignment by never editing an account in the source system once created, instead inactivating it and creating a new one for clarity. - **Metrics reporting:** A request was made to generate and provide weekly metrics on the progress of moving and cleaning up accounts to track the effort's effectiveness. ## DSS Bill Validation Page A major update was presented on a new "Bill Validation" page within the DSS application, which is now live and ready for use. This tool is designed to intercept and correct billing errors *before* they are forwarded for manual processing, aiming to drastically improve efficiency. - **Addressing a large backlog:** Currently, there are approximately 1,200 bills in the validation queue that require review. This backlog is a contributing factor to some missing bills. - **Operational shift required:** The operations team is expected to start using this new page daily from the coming week. The goal is to clear the initial backlog and then maintain it, preventing new bills from piling up. - **Efficiency gain:** Correcting data in DSS is significantly faster than the previous process of handling errors in the downstream DDS system, where all data had to be re-entered manually. Training videos will be provided to facilitate the transition. ## Credentials and Data Alignment The team discussed problems with outdated or missing login credentials for utility portals, which prevent automated bill retrieval. - **Discovery of a new data source:** It was found that current credentials can be viewed within the data services system, providing a starting point for verification. - **Systematic verification plan:** The new process will involve checking these credentials against the master records in SmartSheets and proactively reaching out to customers for updates, especially since many change requests from customers have reportedly gone unanswered for months. - **Resource allocation:** New and existing contractors will be brought into the effort to help clean up the credential list and assist with other data cleanup tasks. ## Project Updates and Operational Changes Several other key projects and system changes were reviewed. - **BP Project Go-Live:** A major project for BP is scheduled to go live at the end of the following week, involving roughly 2,500 meters. A concerning issue was raised about potentially missing credentials for a portion of these accounts. - **Account Linking Process:** For BP and similar projects, there is an ongoing effort to properly link accounts in the system without immediately triggering bill pulls. This process is intended to confirm credentials work and ensure data flows correctly into all downstream systems. - **Issue Tracker Launch:** A new company-wide issue tracker tool is in its final stages and is expected to launch with a training video early in the coming week, followed by a renewed focus on onboarding processes.

Infrastructure cost optimization review targeting the $14.2K/month AWS bill. Identified $3.2K in immediate savings from unused instances. Planned database right-sizing and spot instance implementation. EKS migration deferred to Q2.

## Summary The meeting covered two distinct but critical operational topics: a technical investigation into a data filtering discrepancy within an audit system, and a detailed discussion on aligning credential and vendor data across different platforms. ### Investigation of DSS Audit Queue Filtering Issues A significant discrepancy was discovered when filtering records using different statuses in the DSS audit system, leading to an investigation into data integrity and UI behavior. The core issue revolved around the system displaying inconsistent record counts when filtering by "DSS Audit Queue" versus "Failed DSS Audit Queue," with a difference of approximately 56-57 records. This pointed to potential problems in how statuses are defined and managed. - **Status List Management and Data Source:** The root cause was traced to how status lists are populated in the user interface. It was clarified that these should be dynamically pulled from a Cosmos database container, not statically defined in the code. The team was instructed to query the Cosmos records for unique values from both the `status` and `display_status` fields to build an accurate, clean list. - **Identifying the Record Discrepancy:** The investigation revealed that the "Failed DSS Audit Queue" filter includes an additional status, "failed DS enrichment complete," which accounts for the missing records. It was emphasized that understanding these specific records is vital, as the new system's goal is to allow operators to review and update such builds efficiently. - **Action Plan for Resolution:** The immediate action is to clean up duplicate or legacy status names in the UI's source list. The team will query the Cosmos database to fetch all unique statuses, remove outdated entries, and ensure the filter accurately reflects the live data. ### Credential Management and Vendor Data Alignment The discussion focused on the complexities of managing vendor credentials across the Data Services (DS) and UBM platforms, highlighting gaps in current mapping processes. The primary objective is to ensure that billing account credentials are consistent and accurately matched between the two systems. - **Data Structure and Account-Level Credentials:** A key clarification was that in the UBM system, credentials are stored at the *billing account level*, not the vendor level, and a single vendor can have multiple accounts. This structural difference is central to any matching logic. - **Analyzing the Matching Logic:** Questions were raised about the logic in an existing spreadsheet used for credential matching. Confusion existed around the purpose of two specific flags (`credits present in both` and `account spread in both`), as they appeared to be identical in the sample data. The team needs to determine if account number matching is a prerequisite for credential validation. - **Ownership and Clarification Needed:** The creator of the spreadsheet was identified as the point of contact for clarifying the intended matching logic. The team will conduct further exploration on the test server to understand how the data is currently being filtered and validated. ### Vendor Synchronization and Mapping Between Systems A major challenge identified is the lack of a formal, real-time mapping table for vendors between the Data Services and UBM systems, creating a potential for inconsistent data. - **Unidirectional Vendor Creation:** The process flow was clarified: UBM does not create vendors independently. Vendors are only added to UBM either through a sync API from Data Services or automatically when a new bill is imported for an unknown vendor. Consequently, UBM cannot have a vendor that doesn't exist in Data Services, but the reverse is possible if syncing is delayed. - **Need for a Formal Mapping Table:** It was confirmed that a dedicated mapping table between TS (potentially a third system) and UBM for customer/vendor data does not currently exist and is a required piece of work. The recent fix to the vendor sync API was noted, but its deployment status and effectiveness in production remain to be fully verified.

## Current Task Management System in FDG Connect The meeting began with a review of the existing functionality. Currently, tasks in the system are generated based on a simple, vendor-level "cycle date" configuration. This means a task is set to reappear on a fixed schedule, such as every 30 days, regardless of the actual bill availability. The core function of a task is to notify data services operators that a PDF bill is ready for download from a vendor portal so they can push it to the data system. However, this rigid approach is often inaccurate, leading to inefficiency as operators must manually "snooze" tasks repeatedly when bills are not yet available, adding unnecessary work. ## Proposal for an Advanced Two-Tiered Configuration To solve the limitations of the current system, a new two-tiered configuration model was proposed. This model introduces greater flexibility and accuracy by allowing configurations at two distinct levels, moving beyond the single vendor-level setting. - **Vendor-Level Configuration:** Users can set rules that apply to all accounts associated with a specific vendor. For example, if a water utility consistently posts bills on the 15th of each month, that expected posting date can be set once for the entire vendor, streamlining task scheduling for all related accounts. - **Account-Level Configuration:** This provides an additional layer of control. Users can define scheduling rules for individual accounts. This is crucial for handling exceptions or accounts with billing cycles that differ from their vendor's standard pattern. ## Configuration Types: Expected Posting Date vs. Cycle Days The proposal details two primary methods for scheduling when a task should reappear after completion. - **Expected Posting Date:** This is a fixed calendar date (e.g., the 7th or 25th of each month). It is ideal for vendors with highly predictable, date-specific billing schedules, allowing tasks to be generated precisely when bills are expected to be available. - **Cycle Days (Offset):** This method calculates the next task date based on the previous bill's service date. A user-defined number of days (e.g., 30, 45, or up to 180 days) is added to that date to determine when the next task should appear. This offers flexibility for billing cycles that are regular but not tied to a specific calendar date each month. ## Rules of Precedence and Independence A key principle of the new design is the clear hierarchy between configuration levels. The account-level configuration will always **take precedence** over any vendor-level setting. This ensures that specific rules for an individual account can override a more general vendor rule. Furthermore, the configuration levels are designed to be independent; a user can modify settings at the vendor level without being forced to change account-level settings, and vice-versa, providing maximum administrative flexibility. The existing basic "cycle date" setup will remain as a foundational fallback option.

## Customer The customer is a team responsible for processing and managing utility and vendor bills for a large organization, operating within a data services framework. Their core function involves ingesting, auditing, and processing bills from multiple sources (web portals, email, mail) to ensure timely and accurate payments. They manage a complex vendor and account structure, requiring meticulous tracking of billing cycles and posting dates. Their role is critical for financial operations, focusing on efficiency, accuracy, and reducing manual workload through automation. ## Success The most significant success achieved involves the design and planned implementation of a sophisticated, two-tiered system for managing expected bill posting dates. This solution provides unprecedented flexibility and control. At the foundational **vendor level**, a default posting schedule (either a specific calendar date or a cycle day offset) can be set, applying uniformly to all accounts under that vendor. The major advancement, however, is the ability to **override this schedule at the individual account level**. This granular control is crucial for handling exceptions and vendors with non-uniform billing cycles across their customer base. This feature directly addresses the core operational need to predict when bills will be posted to portals, thereby eliminating the need for teams to manually check hundreds of accounts daily and significantly boosting efficiency. ## Challenge The primary and most persistent challenge is the high volume of duplicate bills, which creates a substantial manual burden and hampers operational efficiency. Duplicates originate from several overlapping sources: accounts enrolled in automated web downloads while also receiving bills by mail, multiple runs of download bots, and technical issues where tasks repopulate in the helper tool. The problem is exacerbated by flaws in the duplicate resolution system itself. The system's reliance on "header information" (invoice date, amount) being populated to correctly identify duplicates means that many legitimate duplicates appear as "unknown," forcing manual investigation behind the scenes. Furthermore, pixel-to-pixel checksum matches do not verify if the original bill was successfully processed, potentially masking underlying data issues. This convoluted process makes duplicate resolution so time-consuming that it often falls to a limited number of specialists. ## Goals The customer's strategic goals center on enhancing automation, improving data visibility, and refining existing systems to reduce manual intervention. Key objectives include: - **Eliminating Manual Email Processing:** Automating the ingestion of bills sent via numerous email aliases and inboxes directly into the processing system, removing the need for staff to manually download and upload PDFs. - **Developing a Gap Reporting Tool:** Creating a dedicated report to easily identify missing bills for specific customers, vendors, and accounts across historical periods, rather than relying solely on the most recent bill data. - **Streamlining the Pre-Audit Process:** Utilizing a new dedicated "Bill Validation" page to efficiently review and correct bills stuck in the system due to data extraction ambiguities, accelerating overall processing. - **Optimizing Source Selection:** Strategically unenrolling accounts from automated web downloads when bills are consistently received reliably and timely via mail to prevent duplicate sources. - **Refining Duplicate Detection Logic:** Improving the system to more accurately flag and resolve duplicates, particularly by ensuring the resolution interface reliably displays both PDFs for comparison.

## **Summary** The meeting focused on improving and streamlining operational processes for bill processing, credential management, and system automation. Key discussions revolved around integrating new data sources, fixing foundational data issues, and establishing new workflows to reduce manual intervention and reactive operations. ### **Arcadia Bill Processing and Data Integration** The core discussion centered on the ongoing integration with Arcadia for automated bill retrieval. While initial data pulls have been completed, the team is grappling with the lack of robust tracking and metadata from Arcadia, which complicates identifying what has been successfully processed. The immediate plan is to continue periodic, filtered data pulls from Ascension, accepting some risk of duplicates, while working to implement a more permanent webhook solution with Arcadia for future data. The goal is to establish a process where Arcadia consistently provides metadata, reasons for failures, and processed data, shifting the team from a reactive "catch-up" mode to a proactive management stance. ### **Operational Workflow and DSS App Enhancements** A significant operational shift was planned to clear a backlog of bills stuck in the DSS application. Over 300 bills are currently awaiting operator review due to failed automated checks, such as missing dates. To address this, a new dedicated page within the DSS app will be created to centralize this review work. DS operations staff will be tasked with actively reviewing and correcting these bills within the DSS system itself, rather than pushing them to another system, to preserve data integrity and audit trails. Training and rollout for this new workflow are scheduled for the following week. ### **Vendor Code Mapping and Data Integrity** A critical data integrity issue was identified regarding vendor code mismatches between the DS and UBM systems. Only 4,200 out of 10,000 DS vendor codes have corresponding matches in UBM, which is causing validation failures and requiring extensive manual fuzzy matching. This gap undermines the ability to accurately process bills and match credentials. The immediate action is to verify the existence of a master mapping list and task the team with creating a definitive and accurate mapping between DS vendor codes, UBM vendor codes, and Arcadia provider IDs. Access to UBM tables has been provisioned to facilitate this work. ### **Credential Management for Arcadia** The process for managing customer credentials sent to Arcadia was reviewed. A major challenge is the manual and time-consuming review of credential accuracy before submission, a process that is not scalable. With approximately 9,000 unique credentials in the system, the team is evaluating how to best transition credential management to Arcadia's platform, for which they are already paying. The focus is on establishing a process where errors are flagged back to the team for correction and ensuring that credential changes over time are tracked and managed systematically, moving away from one-time CSV uploads. ### **Automation of Email Invoice Processing** The need to automate the processing of invoices received via email was highlighted as a key opportunity to eliminate a manual, reactive step. Bills are currently forwarded to a shared mailbox where they can be overlooked, creating backlogs. The proposal is to implement an automation that monitors specified email inboxes, extracts PDF attachments, and feeds them directly into the DSS processing queue, similar to how FTP files are handled. This would provide visibility into the volume of email-sourced bills and ensure they are not forgotten, requiring confirmation of access rights to the relevant email accounts. ### **Build Template System Overhaul** The conversation detailed a major initiative to overhaul the "build template" system, which defines how bill data is interpreted. Currently, the system allows AI to create new templates when none exist, leading to inconsistencies. The new strategy is to make the build template a mandatory, dynamic instruction set for the AI. For new customers, operations staff (DS Ops) will set up accurate templates based on initial bills, possibly with AI-assisted generation for a first draft. Crucially, the system will be changed so that if no template exists, processing stops for manual assignment, ensuring data quality. Enhanced capabilities to add, edit, and audit template changes are being implemented to give DS Ops full control and visibility. ### **SOC2 Compliance Kick-off** The kick-off call for the SOC2 compliance project was held. The process will involve collaboration with the parent company's (Constellation) team, as the compliance framework rolls up to the larger organization. Initial steps involve setting up necessary accesses and clarifying the scope, including confirming which privacy policies apply to the various platforms in use.

## **Summary** This was a discovery meeting focused on preparing a financial software platform for SOC 2 compliance. The primary goal was to gain a comprehensive understanding of the company's product, technical infrastructure, existing security practices, and organizational context to inform the compliance roadmap. ### **Company and Product Overview** The discussion centered on the Utility Bill Management (UBM) platform, a service offering under the Constellation Navigator umbrella. The platform provides analytics and end-to-end bill payment management for commercial clients with multiple locations, such as retail chains, labs, and gas stations. Founded around 2017-2018 and later acquired, the company has a team of approximately 30 people and primarily serves customers in the United States. - **Service Model:** The platform operates on a dual-service model: delivering analytics on utility consumption and costs, and managing the complete payment process for customer utility bills. - **Data Handling:** The system processes customer data (names, addresses) and financial data related to bill amounts and payment methods, but does not store sensitive payment card information (PCI data). Payment execution is handled by a third-party service. ### **Compliance Framework and Initial Steps** The conversation established the foundational approach for the SOC 2 readiness project, noting parallels with other entities under the same corporate umbrella. - **Policy Leverage:** It was confirmed that UBM would leverage existing policies from Constellation Navigator where possible, rather than creating entirely new ones, to maintain consistency and efficiency. - **Documentation Repository:** A key next step is the creation of a centralized document repository (e.g., Google Drive or Confluence) owned by UBM. This will house existing policies (including those from a prior SOC 1 audit), serve as a workspace for developing SOC 2 policies, and store work papers like risk assessments and tabletop exercises before they are uploaded to the Vanta GRC platform. ### **Technical Architecture and Hosting** The technical stack is hosted on Google Cloud Platform (GCP), with a planned migration to Azure in the future. The architecture is modern and containerized. - **Cloud Infrastructure:** The entire application runs on GCP, utilizing Kubernetes for container orchestration, cloud functions for serverless compute, and VMs for databases. Infrastructure provisioning is primarily manual, with some Terraform used for disaster recovery setups. - **Data Storage and Encryption:** Customer data is stored in databases within GCP. The default GCP encryption mechanisms (AES-256) are used for data at rest, with no additional custom encryption layers applied. - **Disaster Recovery:** A disaster recovery strategy is in place, involving the ability to spin up an entirely new environment in a different US region if needed. ### **Security Practices and Controls** The team detailed several existing security measures, highlighting areas of maturity and identifying potential gaps for the SOC 2 audit. - **Identity and Access Management (IAM):** Employee access uses Microsoft 365 (via Constellation) with multi-factor authentication (MFA). The application itself uses Auth0 for customer authentication, with configurable password policies (complexity, history). User provisioning and deprovisioning follow a formal, ticket-based approval process. - **Secrets Management:** Secrets for the application are managed within GCP's Secret Manager, while infrastructure secrets (e.g., database logins) are stored in 1Password. - **Secure Development Lifecycle (SDLC):** A robust SDLC is followed, using GitHub with branch protection rules. Code requires peer review via pull requests, passes through dedicated development, QA, and staging environments, and only specific personnel can merge to the production branch. Static code security scanning is performed using Checkmarx. - **Network and Application Security:** Network firewalls and a recently implemented Web Application Firewall (WAF) are in place. However, there is no dedicated Intrusion Detection/Prevention System (IDS/IPS), and security-specific alerting for anomalies is not currently configured. - **Vulnerability Management:** Regular vulnerability scans are conducted: Checkmarx scans code, and Constellation performs external vulnerability scans (e.g., using Tenable) on a monthly basis, with defined SLAs for remediating findings based on severity. A penetration test for the web application is scheduled to begin imminently. ### **AI Integration and Third-Party Services** The platform incorporates AI in specific, focused areas rather than as a generative AI chatbot. - **AI Usage:** Artificial intelligence is used internally for a core function: ingesting utility bills and automatically extracting data from them. Oversight for this AI/data processing function falls under the data services team. - **Key Vendors:** The service relies on several third-party providers critical to its operation, including Google Cloud Platform (hosting), a third-party payment processor (Subsidiary API), Power BI for reporting, and Auth0 for customer identity. These vendors will be subject to due diligence as part of the SOC 2 process. ### **Organizational Context and Governance** The discussion clarified the company's structure and existing compliance certifications, which provide a strong foundation. - **Corporate Structure:** UBM operates under the Constellation Navigator umbrella and does not have its own separate board of directors or dedicated roles like a Chief Privacy Officer; these functions are managed at the parent company level. - **Existing Certifications:** The development team's parent company is ISO 27001 certified, and the team undergoes regular internal audits as part of this certification, indicating an existing culture of compliance. - **Device Management:** Employees use company-issued devices (from Cognizant) with enforced security policies, including Microsoft Defender antivirus and web filtering tools. Access to corporate networks requires a VPN (GlobalProtect).

## **Summary** The meeting focused on technical progress and planning for several key system integrations and feature developments. Discussions revolved around data cleanup tasks, building new microservices for third-party integrations, optimizing database architecture, and rolling out new validation interfaces. The primary goal was to ensure these components could be completed and deployed efficiently to unblock critical business processes. ### **Ongoing Data Cleanup and Service Tasks** Progress was reviewed on essential data cleanup and the creation of a new service for document processing. Completing these tasks is critical for measuring the impact of recent development work and for enabling new automation. - **Line Item Cleanup:** A process to clean up specific data is pending a final review of database queries before it can be run. This cleanup is a prerequisite for accurately measuring the success of recent work on build templates. - **ARCADE Integration Service:** Development is underway for a new service that will automatically process incoming configurations. The service's role is to trigger a queue, call an external (ARCADE) endpoint with statement data, download the resulting PDF, and upload it to the DSS system. The estimated completion is within the next day or two. - **Other Customer Data Uploads:** There was a question about whether to also process PDF uploads for other customers like Victra and Medline. The decision was to prioritize the core cleanup task first. ### **Database Optimization for Credential Validation** Significant work has been done to restructure the database supporting a credential validation page, resolving performance issues and preparing for new functionality. - **Data Consolidation:** All data from the DSS and UBM databases has been successfully moved to a single, separate table. This fundamental change has resolved previous pagination problems and centralized the data. - **View Creation for Matching Logic:** Multiple database views have been created to logically separate UBM and DSS data. This structure is intended to optimize the upcoming credential matching logic. - **Filter Count Optimization:** A view was created to store counts for each filter option (similar to a shared spreadsheet), but its performance is currently slow. Active work is being done to optimize the query speed before moving forward. ### **Vendor Mapping and Deployment Hurdles** A missing data mapping was identified as a potential future obstacle, and a deployment blocker was addressed. - **Vendor Mapping Gap:** For the validation page filters to work completely, a mapping table is needed to correlate vendor IDs between the DSS and UBM systems. While a similar table exists for clients, one for vendors appears to be missing or outdated. This is currently only needed for filtering, not for core validation functionality. - **Dev Server Whitelisting:** An outstanding issue preventing whitelisting of the development server's IP address was noted. The plan is to proceed with a deployment of recent database changes first to see if the whitelisting is still required for testing. ### **Build Validation Page Development** A new user interface page has been developed to help teams manage and validate "builds" that have failed automated checks. - **Page Functionality:** The new "Build Validation" page displays data for builds with a status of "DS Audit Failed" or "DS Audit Queue," and which are "In Process." It allows users to view details including the page name and account number associated with each build. - **Deployment Priority:** This page is considered a high priority for deployment to production, even if other features are not ready, as it will immediately help operators identify and address problematic builds. The deployment will require carefully cherry-picking the relevant code changes. ### **Reporting Dashboard Planning** Initial planning began for a new reporting dashboard to provide insights into system usage and volume. - **Dashboard Scope:** The planned page or report should display data related to vendors, accounts, and clients. A key metric to show is the monthly number of bills processed through the system, which indicates how often the ARCADE integration is being used. - **Implementation Path:** The initial version may be created in Power BI for speed, with a longer-term plan to potentially integrate it directly into the main application for broader access. ### **Logistical Planning and Next Steps** The meeting concluded with coordination on immediate deployment actions and schedule adjustments. - **Immediate Deployment Actions:** The build validation page will be deployed to a test environment first. Coordinating a production deployment will involve cherry-picking specific changes from the current development branch. - **Schedule Note:** An upcoming public holiday was noted, leading to the cancellation of the next scheduled meeting.

## Summary This meeting focused on a decision regarding the user interface presentation for organizing different types of data or content within a system. The primary goal was to evaluate options that balance user convenience with long-term technical performance and sustainability. ### Interface Organization Options The central topic was determining the best method to segregate or view data currently shared in a common channel, such as Slack, for different purposes. Three main interface solutions were considered: creating a new tab, implementing a filter on the existing page, or developing a completely new report. The discussion acknowledged that while a new, dedicated tab might be the most straightforward and user-friendly option, its feasibility depended entirely on the technical effort and potential system impact. ### Performance as the Deciding Factor A clear and critical constraint emerged: the chosen solution must not adversely affect the system's performance. The sustainability of the implementation was prioritized over the specific type of interface change. - **Primary concern about new tabs:** It was explicitly questioned whether creating a new tab would create a negative "elastic performance impact," referring to the potential strain on database search and retrieval functions. - **Acceptable alternative - Filters:** Should performance be a concern, adding a filter to the existing page was deemed a perfectly acceptable and functional alternative. - **Flexibility on implementation:** The ultimate decision was framed as flexible, with no strong preference for a tab, filter, or separate report, as long as the performance criterion was met. The core requirement was to ensure any new feature is sustainable and does not degrade the user experience through slow load times or system lag.

## Summary The meeting focused on presenting and exploring potential visual interface designs for monitoring billing data at a port, specifically revolving around two key conceptual views for tracking received utility bills. ### Overview of a Potential Port Interface The discussion centered on conceptualizing a specialized dashboard or view for monitoring billing information at a port facility. ### Conceptual Design: Monthly or Daily Billing View One proposed design is a calendar-based view for tracking when specific bills are received. The primary concept is a **monthly view**, though a daily breakdown was also shown as a more complex example. This view would visually group or categorize different bills, providing an at-a-glance understanding of billing activity over time. The exact implementation details of the grouping were acknowledged as less critical at this exploratory stage. ### Conceptual Design: Account-Level Running List An alternative or complementary design presented is a **running list interface** organized by account number. This view would serve as a direct lookup tool to answer specific questions about bill receipt for any given account. Its core function would be to clearly indicate the status of a bill from a particular provider (e.g., Arcadia) and, if received, display the date of the most recent bill. This concept is seen as a potential new presentation format for information currently found in existing reports, specifically the "combined lab late alignment bills report." ### Purpose and Next Steps The presentation of these concepts was intended to initiate a collaborative review and brainstorming session. The goal is to evaluate these interface ideas, gather initial reactions, and determine if they warrant further exploration and development to improve data visibility and monitoring workflows for port billing information.

The provided transcript fragment contains only a brief, introductory statement. There is no substantive meeting content to summarize, as no discussions, decisions, presentations, or topics were recorded beyond an initial greeting.

## Summary The meeting centered on the ongoing integration of Arcadia as a new third-party data provider for automated utility bill retrieval. The discussion outlined the current state of the pilot, identified key operational challenges, and defined the necessary processes and system adaptations to ensure a successful, scalable implementation. The primary focus was on establishing clear ownership of data, building robust tracking mechanisms, and ensuring seamless coordination between internal systems and the external Arcadia platform. ### Understanding Arcadia's Role and Scope **Arcadia functions as underlying data infrastructure, not a full energy management solution.** The platform is designed to retrieve PDFs and JSON data from utilities using provided credentials, but it lacks the business logic and context (like customer or vendor mapping) that internal systems possess. - **Infrastructure, Not Management:** Arcadia's role is strictly to act on credential and account number pairs provided via API. It does not understand the broader customer or portfolio context, meaning all meaning and data relationships must be managed internally. - **Credential Dependency:** Success is entirely dependent on the quality and accuracy of the credentials supplied. Arcadia will return errors for invalid logins, but diagnosing and fixing the root cause (e.g., which internal system is wrong) is an internal responsibility. - **Historical Data Gap:** The system is designed for forward-looking, periodic bill retrieval. It is not intended to intelligently identify or backfill historical data gaps, which remains an internal task. ### Credential Management and System Synchronization **A major immediate challenge is reconciling and cleaning credential data across multiple internal systems before passing it to Arcadia.** The goal is to establish a single, reliable source of truth for credentials. - **Current Fragmented State:** Credentials currently exist across UBM, Data Services (DS), and Smartsheets, often with mismatches. A new, centralized "credential helper" application is being developed to identify discrepancies (e.g., different usernames/passwords for the same account across systems). - **Manual Cleanup Phase:** Initially, mismatches will be exported and assigned (e.g., to contractors) for manual investigation and correction. The corrected credential will then be used for the Arcadia API call. - **Long-term System Sync:** A bi-directional sync between UBM and DS is on the roadmap to eliminate multiple sources of truth. A decision is needed on sunsetting or formally integrating Smartsheets to prevent future data drift. - **New Account Onboarding:** The contract includes Arcadia's help in setting up credentials for new utility accounts. A process must be defined for how these newly created credentials flow back into internal systems to avoid creating a fourth, separate credential silo. ### Tracking, Monitoring, and Accountability **Building internal dashboards and logs is critical to monitor performance, identify failures, and hold Arcadia accountable to SLAs.** Relying solely on Arcadia's portal is insufficient for operational management. - **Beyond the Arcadia Dashboard:** An internal tracker is being built to augment Arcadia's data with internal context (customer, vendor, expected bill dates). This allows for filtering, prioritization, and a clearer view of what percentage of a customer's portfolio is covered. - **Status and Error Mapping:** The integration must categorize why a bill wasn't retrieved: whether it's an internal credential error, an Arcadia-process error, or because the vendor is not supported by Arcadia. Each category requires a different recourse action. - **SLA Enforcement:** To hold Arcadia to its performance SLAs (e.g., 95% of bills within 5 days), internal tracking must definitively show that correct credentials were provided on time and that the delay was on Arcadia's side. Weekly reviews of items aging past 10 days will be necessary. - **Source Attribution:** Bills retrieved via Arcadia will be tagged with their source within internal systems (like DSS and UBM). This is crucial for reporting, understanding coverage, and troubleshooting, though care must be taken to avoid exposing internal sourcing details to customers. ### Data Handling and Ingestion Workflow **The current workflow involves manual steps from API call to final bill ingestion, which will be automated while maintaining existing data quality controls.** - **Manual Pilot Phase:** Currently, PDFs retrieved by Arcadia are downloaded to a local directory and manually fed into the existing DSS ingestion pipeline. This allows the team to monitor for issues like duplicates or performance problems before full automation. - **Leveraging Existing Pipelines:** The long-term plan is for Arcadia-sourced bills to flow automatically into DSS, undergoing the same validation, extraction, and auditing processes as bills from other sources (like BDE or web downloads). No unique, post-ingestion controls for Arcadia data are currently planned. - **Unresolved Ingestion Challenges:** A known issue across all data sources, including Arcadia, is bills that arrive without recognizable account information ("missing client ID"). Solving this likely requires more advanced technical solutions and remains a longer-term challenge. ### Coverage Analysis and Operational Planning **Clear visibility into which utilities and accounts Arcadia can and cannot service is essential for day-to-day operations and resource planning.** - **Vendor Coverage Mapping:** A critical ongoing task is matching Arcadia's supported vendor list against the internal vendor master list. Any mismatch identifies accounts that will *not* be covered by Arcadia and must be fetched through traditional, manual methods. - **Account-Level Visibility:** Coverage needs to be visible at the account level, not just the vendor level, to catch edge cases (e.g., an account missing credentials). This ensures operational teams are not caught off guard by unexpected gaps. - **Influencing Arcadia's Roadmap:** By analyzing uncovered accounts, the company can request that Arcadia prioritize adding support for specific high-volume utilities, providing a path to increasing automated coverage over time. - **Pilot and Duplication:** During the pilot phase, tasks for bills potentially covered by Arcadia will be temporarily snoozed in the internal system to avoid duplicate work. The team acknowledged the need to be vigilant to ensure this does not cause bills to fall through the cracks during the transition.

## Summary The meeting primarily focused on updates regarding current work progress, technical issues, and operational planning. Discussions centered on ongoing development tasks, particularly the assembly of unit tests and the resolution of a significant file reversion issue. There was also coordination around an upcoming system security update to avoid conflicts with other deployments. A notable point of investigation was raised concerning dashboard metrics showing unexpectedly high queue depths for PDF processing, which appear inconsistent with actual system throughput and will be examined further. ## Wins - Significant progress has been made in assembling unit tests, with most of the core coding already completed. - Help was provided to a colleague regarding a separate system task, demonstrating collaborative problem-solving. - Active work has begun on improving a specific report, with an analysis indicating its current inefficiencies stem from multiple contributors over time. ## Issues - A critical setback occurred when a key file reverted to a state from several days prior, requiring a full day of work to rectify. - Progress on the unit tests has been temporarily halted by a combination of a specific bug and project configuration challenges related to separating core functionality into a class library. - A major discrepancy was identified in the queue monitoring dashboard: the metrics for "found" items (PDFs) show a spike to 46,000 and a total near 148,000, which is orders of magnitude higher than the actual number of bills processed (~1,600) and does not align with observed system behavior. The query logic and data source for these metrics require immediate validation. - The team is awaiting crucial advice from a third party (Microsoft) to proceed effectively with the report improvement work. ## Commitments - **Test Development & Deployment:** The unit tests will be completed and pushed. The goal is to finish by the end of Thursday, with a firm commitment not to deploy on a Friday. - **Dashboard Metrics Investigation:** Ownership was taken to investigate the anomalous queue depth metrics shown on the dashboard by examining the underlying log queries and dashboard configuration. - **System Update Coordination:** Plans were made to schedule necessary Windows security updates for early next week (likely Monday) to ensure they don't interfere with other planned production deployments. A confirmation will be sought on Friday. - **Service Work:** Following the completion of a cleanup task, work will commence on a specific service, with an update to be provided on the chosen focus area.

## Summary The meeting began with a personal discussion about managing health issues like morning acidity, stress, and preventative herbal remedies. However, the core of the discussion focused on clarifying and resolving critical data integrity issues within a platform's account management system, specifically the concepts of **linking** and **pairing**. ### Health and Lifestyle Challenges A brief, initial conversation touched upon common modern health concerns, drawing connections between diet, stress, and hereditary factors. - **Acidity and Modern Diets:** Morning throat issues were linked to acidity, exacerbated by modern diets and fasting practices during events like Ramadan. Preventative measures, including specific herbal remedies and dietary awareness, were discussed as alternatives to solely treating symptoms. - **The Impact of Chronic Stress:** It was acknowledged that contemporary life involves significantly more stress and constant information consumption than previous generations, contributing to earlier onset of age-related health issues. However, practical solutions to mitigate this systemic stress were recognized as challenging to implement. ### Clarifying Account Linking A significant portion of the meeting was dedicated to demystifying the process of **linking** virtual accounts, a core function for maintaining historical data continuity. - **Purpose and Process:** Linking is used to consolidate historical data when the underlying components of a virtual account change. It involves connecting an older, closed account to a newer, active one under a single umbrella virtual account to preserve the complete history of a utility service, like a water bill. - **Critical Nuances and Challenges:** The process requires manual selection of the active account, and incorrect linking can lead to operational issues like wrongfully closed accounts. A key assumption is that account changes are permanent and won't frequently revert, an assumption that sometimes breaks down in practice. ### Understanding Account Pairing The discussion then pivoted to the distinct but equally important concept of **pairing**, which is specific to certain utility commodities to prevent data duplication. - **Purpose and Scope:** Pairing is exclusively for natural gas, electric, and lighting commodities in deregulated markets where supply and distribution are separate. Its sole purpose is to prevent double-counting of usage data by logically connecting a supply account with its corresponding distribution account. - **System Fragility and Data Integrity:** The platform was originally built on the assumption that both supply and distribution bills would always be present. This assumption has proven fragile, leading to inconsistent data labeling and unpaired accounts. Proper pairing is essential for generating accurate usage reports, yet it remains an underutilized and poorly understood feature outside of specific, manually cleaned customer datasets. ### Systemic Issues and Root Causes The conversation highlighted that the technical concepts of linking and pairing are hampered by broader, systemic upstream problems. - **Inconsistent Data Entry:** A major root cause of linking errors is inconsistent data entry in upstream systems, such as minor variations in meter ID formatting (e.g., extra spaces). This lack of standardization leads to the unnecessary creation of duplicate virtual accounts. - **Lack of Process Awareness and Consistency:** There is a significant knowledge gap among operators regarding fundamental industry concepts like the difference between "full service," "supply," and "distribution" accounts. This results in incorrectly labeled data from the point of entry, which corrupts all downstream processes, including pairing, and erodes trust in the platform's data. ### The Path Forward and Current Impact The meeting concluded by connecting these issues to real business problems and outlining the necessary focus areas for resolution. - **Immediate Cleanup Needs:** Manual cleanup activities for both linking and pairing are currently required to resolve data discrepancies, especially for newer customers who are experiencing the same historical issues. - **Long-Term Solution:** To prevent recurring problems, there is a critical need to establish consistent data entry standards upstream and to improve operator training on core platform concepts. The ultimate goal is to move from reactive cleanups to a systematic, reliable data onboarding process.

## Summary The meeting focused on a critical data reporting issue related to tracking unpaid or "missing" bills within the company's systems. The core problem identified was that existing reports are polluted by internally created "mock" bills, making it difficult to accurately monitor the status of real customer invoices and identify breakdowns in the billing workflow. ### The Core Reporting Problem: Separating Real from Mock Bills The primary discussion centered on the need for a new or modified report that can accurately display late or missing bills by filtering out any bill marked as a "mock." The current "bills by account" report, used for payment purposes, correctly excludes mocks. However, for operational tracking, a separate view is required because mock bills create significant noise. This noise obscures visibility into whether a real bill was ever successfully acquired and processed in the first place, leading to potential gaps in the payment cycle. ### Understanding the Data Flow and the Point of Failure To understand the necessity of the new report, the complete billing data flow was outlined. The process begins in the data services system, where an actual bill (e.g., a PDF) must be obtained and processed. This processed bill is then sent to the Unified Billing Management (UBM) system. Finally, UBM forwards the bill for payment. The critical failure point occurs at the very first step in data services: if the actual bill is never retrieved or processed, it never enters the downstream workflow. However, teams sometimes create mock bills directly within UBM to placeholder or for other reasons, which masks this initial failure. ### Requirements for the Missing Bills Report The requested report must address the specific shortcomings of the current tools. The key requirement is the **exclusion of all mock or special bills** to present a clean view of only genuine, outstanding customer invoices. This report could be implemented as a new, dedicated view or as an additional tab within an existing reporting interface. The ultimate goal is to provide a reliable tool for tracking the completeness of the billing pipeline, specifically to answer the operational question: "Was this actual bill ever downloaded from the source and pushed to UBM?"

## Customer The customer is a client utilizing the platform for utility bill management and data analysis across multiple locations, such as hospitals and university facilities. Their background involves a significant volume of utility invoices, requiring accurate processing, validation, and reporting to gain insights into energy usage and invoice health. They are deeply invested in using the platform's analytics to drive operational decisions and report to their own stakeholders. ## Success The customer's most significant success with the platform is its **bill health reporting feature**, which they lead with in discussions with their own customers and use as a core analytical tool. This feature acts as a comprehensive pulse check for their entire invoice processing operation. It provides a high-level, visual "heat map" that quickly identifies data completeness and potential issues, such as missing invoices or linking problems, enabling them to proactively manage their utility accounts and demonstrate value. ## Challenge The customer's primary and ongoing challenge stems from **data inconsistencies originating from a third-party data service (DSS)**. The core issue is that utility data is delivered in inconsistent formats, leading to the erroneous creation of duplicate "virtual accounts" within the platform. This results in a cascading problem: the critical bill health reports display false negatives (showing red/errors where data may actually exist but is mislinked), manual cleanup efforts are perpetual, and the customer lacks a single, reliable source of truth for their utility data. This undermines confidence in the platform's core reporting functionality. ## Goals The customer's primary objectives center on achieving data reliability and process efficiency. - **Achieve a clean, accurate bill health report:** They need the platform's flagship reporting tool to reflect a true and accurate state of their data, eliminating false errors caused by systemic linking issues. - **Implement a permanent, systemic solution to data inconsistency:** They seek to move beyond endless manual corrections. The deployment of a standardized "bill template" is seen as the key solution to enforce consistent data formatting at the point of entry. - **Complete historical data cleanup:** While systemic fixes are pursued, there is a strong desire to rectify all past invoices to ensure the entire historical dataset is accurate and trustworthy. - **Streamline communication and onboarding:** There is a recognized need for a more unified communication strategy from the service provider and a desire to establish clear, successful onboarding templates and processes for any future locations or customers they bring onto the platform.

## **Summary** ### **Arcadia Implementation Status and Initial Results** The meeting centered on the ongoing implementation and initial production run of the Arcadia system for automated utility bill retrieval. The primary goal is to transition from manual web downloads to using Arcadia's API, starting with the Ascension customer. - **Initial Ingestion is Complete:** Approximately 1,600 bills for Ascension have been ingested and are processing through the pipeline. The team managed the OpenAI rate limits by staggering the submissions, expecting to complete the initial batch within a 24-hour window. - **Processing is Underway:** Many of the ingested bills have already been processed through the data system (DSS), with some waiting to be pushed to the final destination (UBM). A number of bills were flagged as potential duplicates and are awaiting manual review to confirm and link them correctly. - **Focus on a Controlled Start:** The discussion emphasized a cautious, controlled approach with the first customer (Ascension) to identify and understand system flaws before scaling to others, aiming to avoid repeating past issues experienced with other automated processes. ### **Critical Challenges in Bill Tracking and Deduplication** A significant portion of the conversation dealt with fundamental gaps in the current Arcadia workflow, particularly around tracking and ensuring data completeness. - **Defining and Identifying "Latest" Bills is Difficult:** A major hurdle is the lack of a reliable method to determine which bill is the most recent for an account. Arcadia's data lacks a consistent "statement date," forcing reliance on "due date" or "service period," which can be flaky and may pull in bills from previous months (e.g., December). - **Risk of Processing Old Bills and Missing New Ones:** If the system processes an old bill, it may incorrectly assume the account is up-to-date and snooze the download task for 30 days, potentially causing new bills to be missed entirely until the next cycle. - **Duplicate Management is a Manual Burden:** While some duplicates are caught, the process requires manual verification. The team is concerned about duplicates passing through to UBM and the lack of a scalable, automated resolution process, which creates ongoing operational overhead. - **No Clear Cut-off for Historical Data:** The team had to arbitrarily define a cut-off date (January 1st) for the initial historical pull, acknowledging this will capture some older bills and lacks precision. ### **Credential Management and Data Quality Hurdles** The discussion highlighted that the success of Arcadia is predicated on accurate underlying data, which currently has significant quality issues. - **Incorrect Credentials Block Automation:** A large number of account credentials stored in the core database are incorrect or outdated. Arcadia cannot process these, so they remain stuck, requiring manual intervention to research and correct the credentials-a task that currently lacks a dedicated owner or streamlined process. - **The "Last Mile" is Still Manual:** Even with Arcadia automating the PDF retrieval, several preparatory and cleanup steps are completely manual. This creates a bottleneck and means the promised efficiency gains are not yet fully realized. - **Data Issues are Intertwined:** Problems with credential management and bill tracking are deeply connected, making it difficult to isolate "Arcadia-specific" issues from general data quality problems that the team already struggles with. ### **The Need for Enhanced Visibility and Reporting** A key conclusion was the urgent requirement to build internal monitoring and reporting tools that sit outside of Arcadia's own dashboard to gain true operational control. - **Arcadia's Dashboard is Insufficient:** Its interface does not show customer context, expected vs. received bills, or lateness. The team needs a unified view to track what was sent to Arcadia, what was returned, and what failed (and why). - **Proposed "Arcadia Status" Dashboard:** The idea is to create a dedicated view that tracks, for each customer/account: credentials sent, Arcadia processing success/failure, the resulting bill IDs, and downstream processing status. This would clearly separate Arcadia-stage issues from other data problems. - **Visibility Precedes Full Automation:** The team agreed that building this visibility is a prerequisite for having the confidence to onboard more customers, even before a fully automated "service" is built. It is necessary to measure progress and identify specific, scoped problems. ### **Strategic Planning for Future Onboarding and System Evolution** The conversation looked ahead to the steps required to move beyond the pilot phase with Ascension and build a sustainable system. - **Pausing Further Customer Onboarding:** A decision was made to not immediately onboard the next customers (Park Ohio, BNB, Medline). The priority is to first analyze the complete results from the Ascension run, build the internal reporting dashboard, and understand the failure modes. - **Testing Webhooks for Future Automation:** Once credentials are verified, the plan is to test Arcadia's webhook feature on a few accounts. This would allow bills to be pushed automatically as they become available, moving away from manual polling and closer to a real-time service. - **Long-term Vision for a Scheduled Service:** The ultimate goal is to develop an internal service that automatically calls Arcadia's APIs on a schedule to fetch the latest bills, replacing all manual scripts and processes. - **Addressing Ancillary Issues:** It was noted that Arcadia's JSON output contains less data than the internal system's output, meaning for some bills, both the PDF and the JSON might need to be ingested in the future-an optimization problem to be tackled later. - **Brief Update on URI Linking:** The meeting ended with a brief update on separate URI linking issues reported by sales. This is a known, manual process for the data services team to resolve and is not currently affecting financial reporting, but it remains a point of external friction.

## **Summary** This meeting served as a status check on the deliverables scheduled for January and a preliminary look at the plans for February and March. The primary focus was on the progress of several key reports, resolving underlying data discrepancies, and adjusting timelines based on current priorities and newly emerged, significant work. ### **Progress on January Deliverables** The discussion centered on confirming the status of several items due for completion in January, with mixed progress noted. - **Uncashed Check & Data Validation Reports:** Active work is underway to reconcile data discrepancies. The immediate plan involves comparing a new uncashed check report from the pay system against existing Power BI data to identify and call out mismatches, a task expected to be completed within the month. - **System Status & Review Rules:** The timeline for the system status report is under review and may be deferred to February due to shifting priorities from leadership, despite technical feasibility. The review of rules has seen minimal activity in January but is still anticipated to be reasonable for a February completion. - **Data Validation Errors:** The need for this specific deliverable is expected to become obsolete. A new invoice/build template currently in testing is projected to eliminate the underlying issues that necessitated this work, effectively resolving the task. ### **Report Format and Finalization** A clarification was sought on the preferred platform for delivering the finalized reports, leading to a decision on the workflow. - The team confirmed that the immediate priority is validating the correctness of the report logic and data, not the delivery platform (Appsmith vs. Power BI). The validation and comparison will be conducted within Appsmith first. Once the report is verified and signed off, it can be migrated to Power BI for broader accessibility, contingent on resolving any license access issues for the development team. ### **Planning for February and March** The roadmap for the upcoming months was reviewed, with adjustments made based on the January progress and new information. - **February Focus:** Key items include continuing the work from January, developing a holistic UBM view account, gaining clarity on MFA downloads, and addressing specific customer issues. - **Scope Reduction for March:** Work planned for March on integrity and interpretation layouts is still expected but will likely involve a greatly reduced scope. This reduction is due to other solutions in progress that will address part of the original need, making the remaining work more manageable within the timeline. ### **Introduction of Unplanned Major Work: Arcadia Integration** A significant, unplanned effort was highlighted as a major current focus, impacting the team's capacity. - A new, high-impact project to integrate with a third-party solution, Arcadia, has begun in mid-January. This integration is a strategic shift to address challenges in downloading builds on time, moving the process from an in-house operation to a third-party service. This effort is consuming substantial resources and is expected to continue through February, which has prompted its formal recognition as a separate line item in planning due to its scope and executive interest.

## Summary The meeting centered on critical project timeline adjustments, unresolved requirements blocking progress, and the need to formally reset expectations with an external team. The core issue involves delaying a Go Live date due to missing information, while parallel workstreams for account setup and legal documentation continue. ### Project Timeline and Go Live Date Reassessment A major decision was made to formally push back the project's Go Live date due to unresolved requirements from another team. The original date of March 31st is now considered unachievable because essential information needed for development has not been provided, despite prior warnings. - **Formal Date Change Required:** It was agreed that continuing without a new date creates an unrealistic expectation to hit the original deadline. The team concluded that providing a new, caveated Go Live date is necessary to draw a line in the sand and manage stakeholder expectations. - **Proposed Timeline Adjustment Process:** To protect the development team, a new task for "Scope Confirmation" will be inserted into the timeline. This allows for a dedicated period (suggested as one week) to assess any finally received requirements *before* committing to a development duration. The requirements gathering phase itself was proposed to be extended to November 30th. - **Communication Strategy:** The updated timeline, showing the pushed-out dependencies, will be presented on an upcoming Thursday call with the broader group. A courtesy heads-up via email may be sent beforehand to a key stakeholder, referencing a prior conversation about potential delays. ### Requirements and Development Blockers for Reports Progress on specific reports is completely stalled, as development cannot begin without critical answers from the signing team. Three outstanding requests have gone unanswered, preventing accurate estimation of the work required. - **Unanswered Requests Halt Progress:** The development team cannot confirm if the original 30-day development estimate is valid or even if the requested features are technically achievable due to the lack of detailed requirements. This uncertainty is the primary driver for the overall project delay. - **Path Forward with Dependencies:** The plan is to use the upcoming customer reports call to seek these answers. If the information is not received, a separate follow-up call will be necessary. The development of these reports is a key dependency for other project phases. ### Account Setup and Migration Status The migration of accounts from the legacy system (Data Services) to the new platform (UBM) is behind the previously communicated schedule, currently at only 31% completion. - **Current Progress Metrics:** Out of approximately 6,450 total bills, 2,018 accounts have been successfully migrated to UBM, and 4,344 have been processed through the account setup queue. A subset of these (3,235 non-EDI bills) is currently in an audit state. - **Revised Completion Date:** The estimated completion date for migrating all non-EDI accounts (including setup and mapping in UBM) was pushed back to December 6th. This acknowledges the current resource allocation and provides a more realistic buffer. - **Handling Final Bills and EDI:** A process question was raised regarding identifying "closed accounts" for reporting purposes, which depends on utilities correctly flagging final bills. Additionally, roughly 1,000 EDI-formatted bills are currently suspended, awaiting a separate green light and legal agreement (LOA) before their migration and outreach can begin. ### Legal and Banking Dependencies The project's timeline is intertwined with external legal and banking processes that are proceeding on separate tracks. - **Letter of Agreement (LOA) Urgency:** The finalization of a master LOA is a critical dependency, especially for initiating outreach on the suspended EDI accounts. While work is ongoing, it was noted that if the agreement slips into February, it could become a project risk. A call with legal counsel is scheduled to advance this. - **Banking Setup Confirmation:** For a separate workstream (FBO), banking documentation from a client has been submitted and confirmed. However, the actual bank account setup is not yet visible in the system, though this is not expected to be an issue. - **BAI File Sample:** A follow-up is required on a request for a BAI sample file from another team member, which remains an open item.

## **Ongoing Customer and Operational Challenges** The meeting opened with a discussion of persistent external and internal operational pressures. A significant, long-standing issue with a customer who has not paid a substantial debt for over a year was highlighted, exemplifying ongoing accounts receivable challenges. Furthermore, a recurring theme was the influx of complaints and data inconsistency issues from various teams, particularly as they conduct month-end reporting, which is putting a strain on resources. There is also concern about client retention, with specific mentions of threats from customers like "Ascension" and "Apex" potentially dropping services, though "Sheets" was noted as a more understanding long-term client. Operationally, there are questions about the efficiency and focus of the operator assigned to the "Sheets" account, with observations that the workload metrics may not reflect productive output. ## **Updates on Technical Projects and Processes** A primary focus was the status of several key technical initiatives aimed at improving data handling and reporting. The implementation of a new template for processing data is complete; however, the current effort is focused on cleaning up thousands of redundant line items in the build templates created over recent months, a task that requires careful validation to avoid deleting necessary data. Concurrently, credential management system updates are slated for completion within the week, which will provide a user interface for reviewing and updating access credentials. - **Template Implementation & Guardrails:** The new data ingestion template is in place. A major related task is the cleanup of accumulated build template line items, with work targeted for completion this week. A recognized risk is that the AI may sometimes ignore the provided template, so plans are being made to establish guardrails and a review process for such exceptions, though the high volume of data poses a challenge for manual oversight. - **Credential Management:** A UI for credential management is nearing completion and expected to be finalized within the week. ## **Prioritization of Analytical Reports** A significant portion of the conversation centered on prioritizing the development of several analytical reports to improve visibility and operational control. The "Arcadia Report" (internally named for tracking purposes) was given top priority as it is deemed essential for identifying missing bills-a critical gap in current processes. A "Missing Bills Report" is also needed and is considered a quicker development task. Additionally, there are two other dashboard requirements that require weekly maintenance. The approach moving forward is to formalize a prioritized list of all report development work to manage expectations and streamline the workflow for the data engineering team. - **Arcadia Report (Top Priority):** This report is considered the fundamental tool for tracking actual missing bills, addressing a core operational blind spot. - **Missing Bills Report:** This is identified as a simpler, quicker report to develop in parallel. - **Formalized Prioritization:** To manage the constant influx of reporting requests, a comprehensive and prioritized list of all required reports and dashboards will be circulated to align the team and set clear expectations for delivery timelines. ## **Internal Communication and Alignment Issues** Friction and misalignment within the broader organization were a notable topic. An incident was recounted where a manager, several levels removed, publicly expressed a lack of awareness about ongoing projects and releases, despite a recent comprehensive year-end review meeting that covered these exact topics. This has prompted a decision to institute more frequent, structured communication, such as a dedicated monthly meeting, to keep that part of the organization informed. The discussion also touched on a separate communication issue with another team ("Ura"), where key representatives have stopped attending meetings, leading to information silos. ## **Specific Action Items and Follow-ups** The meeting concluded with plans to address several specific pending items. Immediate follow-ups are required with data engineers "Ruben" and "Jay" regarding a "linking pairing" issue for a client, as a previous meeting was missed. Furthermore, an email from "Jennifer" regarding data cleaning for "Exponent" needs to be reviewed and addressed, with clarification needed on whether it relates to previously discussed work. The team is also working through a list of client accounts that need attention before the end of the month.

## **Summary** The meeting focused on three primary technical workstreams: clarifying data source columns for billing systems, reviewing development progress on a validation and filtering interface, and planning a bulk data ingestion process with considerations for system performance. ### **Clarification of Data Columns and Sources** A detailed discussion was held to identify and understand the specific data columns related to bill creation, particularly their sources and overlapping information. The goal was to establish clear definitions and fixed possibilities for these data points to ensure consistent handling across platforms. - **Analysis of key columns:** The conversation centered on columns like `created by user` and `bill source`, which are present in systems like FTG Connect and UBM but may not be uniformly displayed everywhere. Identifying all relevant columns and their possible values (e.g., web download, mail) is a prerequisite for systematic data work. - **Verification of data origin:** There was a point of clarification regarding whether the `bill source` data is set within the application's own data services or originates from the upstream UBM database, highlighting the need for technical verification to confirm the system of record. ### **Development Progress on Validation Page & Filters** Significant progress was reported on a validation page, with new filtering capabilities being implemented to manage and review records more effectively, though some data mapping challenges remain. - **Enhanced filtering interface:** Client and vendor dropdown filters have been added to the page, enabling users to filter DSS records based on these selections. The client filter is fully functional due to an existing mapping table between DS and UPM databases. - **Outstanding integration challenge:** A current blocker is the lack of a mapping table for vendors between the UBM and DSS databases, preventing the vendor filter from populating correctly with matched records. Development is ongoing to resolve this data linkage issue. - **Additional feature work:** A parallel task involves implementing record count displays for each filter option, providing immediate visibility into how many records are returned when a specific filter criterion is applied. ### **Deployment Strategy and Environment Updates** The team reviewed the state of various features across development and production environments, leading to a decision on pushing recent changes for broader testing and review. - **Assessment of lower environments:** It was confirmed that several features, like edit history and PDF/B list viewing, are already present in lower environments (e.g., Build Management), while other JavaScript components are only in production. - **Decision to deploy:** To enable hands-on review and testing of the new validation page features, a decision was made to push the current development changes to a lower environment (dev server). This will allow for practical evaluation and any necessary adjustments before further progression. ### **Planning for Bulk Data Ingestion** A major operational plan was formulated to execute a large-scale ingestion of historical billing data, with careful attention to system load and queue management to avoid performance degradation. - **Scale and execution:** The plan involves processing a substantial backlog of data, estimated at 700-800 items, with an understanding of the total account volume being around 3,000. The ingestion will be performed via a script with a controlled delay (e.g., 5 seconds) between uploads. - **Queue management strategy:** To prevent system overload, a detailed analysis of existing queue backlogs (Priority, Prepay) was conducted. Since current backlogs were minimal, the team decided to proceed with the ingestion while closely monitoring system metrics. - **Performance safeguards:** The ingestion will utilize a separate processing path that bypasses the main priority queues, uploading directly for processing. The team committed to real-time monitoring of queue throughput and system performance during the execution to swiftly address any potential spikes or issues, ensuring stable operation for other ongoing processes.

## **Overview of the Billing Data Download Workflow** The meeting focused on improving the efficiency and logic of the bill download and task management process within the Web Download Helper system. The primary goal is to reduce the significant amount of manual work currently required by the operations team to manage and snooze tasks for bills that are not yet available. Discussions centered on three main areas: enhancing the task snoozing logic, introducing dynamic expected posting dates, and reviewing updates to the invoice template system. ## **Purpose and Issues with the BDE Flag** The meeting clarified the intended use of the BDE flag and identified operational inefficiencies it was meant to address. The flag is designed to signal that an account's bill is expected to be pulled by a third-party service (BDE), not to automatically snooze tasks. However, a key problem was identified where operators still manually pull these bills, leading to duplicate work. The team discussed integrating a weekly report from BDE, which lists active accounts and their expected pull dates, to better synchronize expectations and task generation, moving beyond a one-size-fits-all snoozing logic. ## **Revamping Task Snoozing Logic & Workflow** The current snoozing functionality was deemed too static and labor-intensive, prompting a deep dive into potential solutions. The core issue is that the team spends excessive time checking portals for bills that systematically post later than the invoice date. - **Current snooze mechanism:** The system only allows a task to be hidden for a fixed two-day period before it repopulates, requiring repeated manual intervention. - **Dynamic date adjustment proposal:** The conversation shifted towards creating a system where an "expected posting date" can be defined, preventing tasks from appearing until the bill is actually available online. - **Challenges with cycle days:** Relying solely on cycle days (days from the service end date) is problematic because many vendors have delayed posting schedules or inconsistent billing cycles (e.g., quarterly bills, municipalities with fixed monthly posting dates). ## **Proposal for Vendor & Account-Level Expected Posting Dates** A two-tiered configuration system was proposed to automate task scheduling and drastically cut manual snoozing. This solution aims to set expectations systematically so the system "doesn't even bother looking" for a bill until it is likely to be posted. - **Vendor-level configuration:** For vendors where all accounts follow a uniform schedule (e.g., a municipality that posts all bills on the 15th of every month), a global expected posting date or delay could be set. This would apply as a default to all associated accounts. - **Account-level override:** For vendors with inconsistent billing cycles across different customers, the system would allow operators to set an expected date or cycle day override on specific accounts. This is crucial for vendors where one customer might be billed monthly and another quarterly. - **Implementation strategy:** The team acknowledged that populating these settings would be a gradual, manual process done over several months as bills are processed, rather than a massive upfront data migration. ## **Manual Reporting Process and Automation Potential** Significant time is spent on a manual weekly report to identify late bills, highlighting an area ripe for automation. This process currently involves complex filtering in a spreadsheet to isolate bills that are 35 days or older from their last invoice date while excluding those with future expected dates. - **Time consumption:** The manual report takes several hours to compile, representing a major efficiency drain. - **Automation goal:** Even if full automation isn't immediately feasible, the priority is to explore ways to reduce this task from hours to 30 minutes or less by leveraging or modifying existing system data like the outstanding web download report. ## **Updates to Invoice Template and Error Resolution** Progress on the invoice template system was demonstrated, and a specific billing error was reviewed to establish a resolution protocol. - **System enhancements:** Updates allow users to view the specific invoice template used for any processed bill directly from the bill's details, including templates with incorrect line items for reference. - **Handling "failed" bills:** The team examined a failed bill that lacked clear start/end dates because it was a print-out from a web portal. It was determined that for such cases, the bill date should be used as the service date. - **Workflow decision:** A decision was made that for bills failing pre-audit due to minor correctable issues (like missing dates), it is more efficient for the operations team to edit them directly within the system rather than having them routed through a separate ticket-based system, which would require re-entering all data.

## Summary The meeting centered on designing a new, unified system for ingesting utility invoices, primarily focusing on Constellation electricity bills, with additional discussions on handling gas bills and resolving data issues with a specific client (Ascension). The goal is to create a streamlined, centralized service that avoids redundant requests to external teams and minimizes changes to existing data structures and customer relationship management (CRM) systems. ### Constellation Invoice Retrieval Strategy The core proposal involves leveraging an existing file storage container ("Navigator" style) to receive all Constellation customer bill PDFs and XMLs automatically. - **Centralized Container Approach:** Instead of each application team making separate requests, the plan is to ask the external data team (ADT) to replicate a storage container where all Constellation bills are deposited. This provides a single source of truth for applications like Data Services (DSS) and UBM to pull from. - **Minimizing External Team Impact:** A key objective is to present a comprehensive, unified request to the ADT ("Shooting team") to prevent them from receiving conflicting or piecemeal demands from different internal teams. This involves specifying the exact need: a container with appropriate permissions and a Shared Access Signature (SAS) token that grants full manipulation rights (read, write, delete). - **Proving Feasibility:** A similar setup is already functioning for a different purpose (carbon accounting/GHC container), which provides a working blueprint and suggests the implementation timeline could be relatively short (a few weeks). ### SRT System and LDC Mappings The conversation clarified how customer and account identification would work within the new flow, relying on the existing SRT (Service Request Tool) system. - **Customer Identification via CNE ID:** The Customer Network Entity (CNE) ID, obtainable from the CRM (HubSpot), serves as the primary customer identifier. This ID has a one-to-many relationship with Local Distribution Companies (LDCs). - **Account Specification via LDCs:** An individual customer (CNE ID) can have multiple utility accounts, each represented by a unique LDC number. The SRT tool can provide the full list of LDCs associated with a given CNE ID, which is necessary for pinpointing specific account bills within the storage container. - **Processing Latency Unknown:** A remaining open question is the latency of the file replication job-how frequently new bills are copied into the container-which requires further testing by attempting to drop a file and observing the sync time. ### File Handling and Proposed Storage Solution The discussion covered how applications would access the bills from the central container and proposed an intermediate storage layer for flexibility. - **Intermediate S3 Bucket Proposal:** As a short-term solution, a process would fetch files from the Constellation container and drop a copy into an internal S3-compatible bucket. This provides a more accessible and controllable API endpoint for internal applications. - **Enhanced Control and Traceability:** Using an internal bucket allows for adding event tracing, logging, and metadata tagging (e.g., LDC, date). Applications could call an API to list available files for a given LDC and date range before retrieving the specific PDF or XML, improving reliability and auditability. - **Managing File Lifecycle:** Questions about automatic "soft deletes" in the source container and how to handle file versioning were acknowledged as important details that need to be understood and configured within the new system's logic. ### Gas Bill Ingestion Challenges Extending the solution to gas bills presents significant technical hurdles due to different source systems and access limitations. - **Separate Source System (RBS/Genesis):** Gas invoices are held in a separate system (RBS/Genesis) managed by a different team (Laserfish), not in the same pipeline as electricity bills. - **Access and Network Barriers:** Current access methods are problematic. One method provides a SAS token that expires weekly and requires manual renewal, while another (Laserfish) is inaccessible from outside the corporate network, rendering it useless for an automated external service. - **Longer-Term Integration Question:** The fundamental challenge is whether the gas bill data can be integrated into the same logical flow. One potential solution explored is requesting that the Laserfish team deposit gas bills into the same centralized container, creating a unified "Constellation bills" stream, regardless of utility type. ### Ascension Data Cleanup and Date Filtering An immediate, practical issue was addressed concerning a specific client's data, which contained duplicate and outdated bill files. - **Duplicate and Old Bills:** The dataset received for the Ascension client included bills dating back to February and March, leading to unexpectedly large file sizes and duplicate ingestion efforts. - **Plan for Filtering:** The immediate action plan is to use a provided script to parse the accompanying JSON metadata files (which correspond to each PDF) to identify and exclude all bills dated prior to January 1st. This will create a clean list of only the relevant, recent PDFs to ingest. - **Broader Date Definition Issue:** This problem highlighted the ongoing, critical challenge of standardizing date parameters (e.g., invoice date, statement date, service period) across different systems and teams to prevent similar issues in future automated retrievals.

## Customer The customer is a strategic partner operating in the energy or facilities management sector, using the platform for comprehensive utility bill management. This client, referenced as Hexpo (or Hexable), manages multiple entities under their portfolio, including St. Elizabeth and Munson. Their role involves accruing costs, analyzing usage, and generating consolidated reports from utility data across numerous locations and accounts. Their background suggests a sophisticated, data-driven operation where billing accuracy and report integrity are critical for financial operations and sustainability reporting. ## Success The customer's most significant success with the platform lies in their proactive and detailed internal audit capabilities. Faced with pervasive data inconsistencies, their team undertook a substantial manual effort to identify discrepancies. They created extensive, customized reports and spreadsheets that meticulously flagged issues the platform failed to catch automatically, such as incorrect account linking and implausible usage figures (e.g., unit of measure errors). This self-driven diagnostics work was crucial in highlighting the severity and specific nature of the platform's data integrity problems, effectively prioritizing the most critical fixes and preventing complete operational breakdown in their reporting. ## Challenge The single biggest challenge is the platform's persistent and systemic **data linking and integrity issue**. This core problem manifests in several critical ways: - **Account Linking Errors:** Virtual accounts (representing utility services like distribution, supply, or full service) are not correctly linked to their physical locations or to each other when they should be. This results in split bills, duplicated accounts, and invoices posted to incorrect entities, making consolidated reporting impossible. - **Propagation of Bad Data:** The decision to turn off automated validation checks in the platform months ago allowed errors to be "auto-resolved" without human review. This created a massive backlog of potentially incorrect bills where it's now impossible to distinguish between data that was manually corrected and data that is fundamentally flawed. - **Impact on Core Functionality:** These issues directly undermine the primary value proposition of the platform. Customers cannot trust the accrual reports, usage analytics, or carbon reporting, rendering key features unusable and threatening contract renewals. The problem is compounded because bulk-fixing tools often fail when accounts are already incorrectly linked, forcing highly manual and unsustainable correction processes. ## Goals The customer's primary objectives in using the platform and engaging with the support team are clear: 1. **Achieve Data Accuracy:** To have all utility bills correctly linked and accurately reflected in the platform, ensuring that cost accruals and usage data are reliable for financial and operational decision-making. 2. **Restore Reporting Confidence:** To be able to utilize the platform's analytics and reporting features without manual workarounds or external spreadsheets, trusting that the data presented is a single source of truth. 3. **Implement a Sustainable Solution:** To move beyond one-off, manual cleanup efforts. The customer needs a systemic fix-whether through new platform logic, templates, or enhanced validation-that prevents these linking and data integrity issues from recurring with new invoice processing. 4. **Ensure Platform Stability for Contract Renewal:** To resolve these critical issues to a satisfactory level before key contract renewal dates, as the current state poses a direct threat to the continued business relationship.

## **Summary** The meeting centered on critical operational and reporting challenges within the utility bill management system, focusing on the need for a single, reliable source of truth for tracking bills, resolving systemic data issues, and developing more advanced analytical capabilities for clients. ### **Establishing a Reliable Bill Tracking Methodology** The core problem identified was the lack of a unified, clear view to determine whether all expected utility bills have been received and processed. Different reports (e.g., "Late Arriving Bills" vs. a "Missing Bills" report) create confusion. - **Defining a clear tracking view:** The discussion emphasized moving away from ambiguous "lateness" metrics based on unreliable expected dates. Instead, a simpler "have/don't have" status check for each account was proposed, potentially categorized by billing cycle, which is often published in advance by utilities and is more stable. - **Need for a single source of truth:** A significant challenge is data fragmentation across multiple systems (Data Services, UVM) and intake sources (Arcadia, BDE, web downloads, mail). The team stressed the necessity of one consolidated list that defines the 100% of accounts expected, against which all incoming data can be measured, to know precisely what is missing and from which source. - **Communication of systemic issues:** The group noted that third-party data providers like Arcadia may have statuses for utility billing outages, but this communication needs to be integrated into the internal tracking process to avoid unnecessary follow-up on accounts where delays are known. ### **Addressing Operational Data Integrity Hurdles** Several ongoing operational issues directly impact the accuracy of reporting and client trust, primarily concerning duplicate bills and data synchronization. - **The duplicate bill crisis:** A major operational burden was highlighted, where thousands of duplicate bills are processed weekly. This is exacerbated by changes of address (where web downloads and paper mail run concurrently) and failures in the duplicate resolution system, particularly when bills lack a clear invoice date. - **Impact on client confidence:** Passing duplicates through to the client's view undermines the promised validation checks and forces manual remediation, creating a significant credibility issue. - **Discrepancy management:** There remains a reporting gap and discrepancies between what is present in the Data Services (DS) platform versus what appears in the UVM system, both for accounts and credentials. This gap prevents a clear picture of data flow and completeness. ### **Developing Advanced Reporting for Energy Management** The conversation shifted to the need for the platform to evolve beyond basic bill pay into a true energy management tool, identifying a key reporting gap. - **The critical need for a Rolling 12 report:** A standard report in the industry, the Rolling 12-month view, is currently difficult or impossible to generate within the platform for a custom fiscal year. Clients and internal energy managers are forced to manually compile multiple data exports. - **Value of advanced analytics:** This type of report is essential for finance teams to understand run-rate, compare year-over-year performance, track against budget, and identify consumption anomalies that could signal equipment issues or energy efficiency opportunities. Its absence limits the platform's value proposition and forces clients to perform analysis externally. - **Expanding use for CES:** The Commercial Energy Services (CES) team requires these analytical capabilities to proactively identify savings opportunities for clients, aligning the platform's functionality with the broader value sold during the sales process.

## **Reports and Data Discrepancies** The meeting began with a focus on several reports, particularly those being prepared for January. There are ongoing efforts to align data between different systems, with specific discrepancies identified between data pulled from a platform called PayClearly and what is being displayed in Power BI reports. An investigation is planned to resolve these mismatches, which could be due to timing issues in data refreshes or missing data fields. - **Addressing data alignment issues:** A key task is to reconcile summary reports created from PayClearly exports with the views available in PowerBI. A meeting was scheduled to analyze specific examples of these discrepancies to determine if they are caused by timing delays in API data refreshes or by fundamentally missing information. ## **Credential Management and Validation** Progress is being made on a credential management project, which is a key multi-year initiative. The core credential management component is targeted for completion within the next week, to be followed shortly by a validation piece. This work is foundational for onboarding customers to a platform named Arcadia. - **Upcoming completion and ownership:** The credential management system itself is on track for completion imminently, with the validation component to follow about a week later. Once finished, ownership of the validation process will be transitioned to another team, and customers will be onboarded to Arcadia in a phased, one-by-one manner. ## **System Status Report and Upcoming Reporting Tasks** The system status report is considered complete from a development standpoint, though it requires feedback and likely some adjustments. A broader list of approximately nine other reports is in the pipeline, encompassing both new reports and adjustments to existing ones. - **Prioritizing a queue of reports:** A comprehensive list of all pending report requests will be circulated internally to confirm priorities and requirements. This will help the team sequence the work effectively alongside other quarterly goals. ## **MFA Strategy and Arcadia Integration** A significant discussion centered on the strategy for Multi-Factor Authentication (MFA). There is an active evaluation of whether to invest in a new MFA solution or to rely on the capabilities provided by the Arcadia platform as more services migrate there. - **Evaluating the need for a new MFA solution:** The team is assessing whether procuring a separate MFA technology (to move away from using personal phones) is still necessary if most systems are transitioning to Arcadia, which has its own MFA system. This decision hinges on understanding the timeline and scope of the migration. - **Understanding the current MFA landscape:** As part of this evaluation, the team needs to build a complete inventory of which vendors or systems currently require MFA and where those authentication assets (like phone numbers) are assigned today. This will clarify the scale of the problem for any remaining non-Arcadia systems. ## **Quarterly Roadmap and Upcoming Priorities** The conversation reviewed the Q1 roadmap to ensure the team remains on track, with an emphasis on completing January deliverables to maintain momentum. Several projects for February and March were previewed to allow for advance planning. - **Maintaining Q1 momentum:** The team expressed confidence in completing most planned Q1 work but acknowledged the tight timeline. The goal is to avoid slippage by completing January tasks promptly, as the schedule for subsequent months is already full. - **Key initiatives for February:** February's focus includes data validation errors, credential management tasks, a review of rules, and the addition of a holistic account health dashboard in Power BI. The MFA strategy discussion is also a key February milestone. - **Potential scope reduction for future projects:** Two upcoming initiatives-an "interpreter layer" and phases of "integrity checks"-may be significantly reduced in scope or eliminated entirely. Changes to the build template and the Arcadia integration could make these efforts redundant. The "review of rules" project may also help address the integrity check requirements.

## **Summary** This meeting focused on critical operational and technical challenges related to system integrations, data consistency, and reporting backlogs. The primary goal was to advance the integration with **Arcadia** for automated bill processing while simultaneously addressing systemic issues in credential management and the overwhelming demand for new reports. ### **Progress and Plan for Arcadia Integration** The immediate plan is to complete the first major ingestion of data from Arcadia, with processing expected to begin the following day. The initial test involves a 150MB data batch to validate the processing scripts before handling the full volume. The integration aims to automate the ingestion of billing PDFs, moving away from manual downloads, but the immediate focus is on ensuring the technical pipeline works correctly before scaling. - **Initial Batch Processing:** The team plans to start with a secondary data batch to test the script's functionality, as the first batch requires filename adjustments. Success with this test will confirm the pipeline is ready for full-scale operation. - **Addressing Duplicates and Failures:** Initial data from Arcadia has already been processed, resulting in some duplicate entries and expected system failures (e.g., bills with invalid formats or currencies). These are considered normal outcomes of integrating a new data source and will be handled through existing operational workflows. - **Long-Term Source Identification:** A crucial next step is to formally tag all data sourced from Arcadia within the system. While the origin can currently be traced in the backend, this needs to be surfaced as a filterable attribute for operations and reporting clarity. ### **Identifying and Classifying Potential System Failure Points** A significant part of the discussion centered on proactively defining categories for potential failures in the Arcadia pipeline. The objective is to correctly attribute issues to avoid incorrectly blaming the new integration and to establish clear troubleshooting workflows. - **Credential Mismatches:** A primary anticipated issue involves discrepancies between account credentials stored in different systems (UBM vs. DS). This could prevent Arcadia from successfully accessing bill data. - **Vendor Mapping Errors:** Failures may occur if the identifiers used by Arcadia do not correctly map to internal vendor IDs, as was a challenge with the Ascension account. - **Establishing Expected Behavior:** The team emphasized the need to define what "correct" processing looks like to effectively identify anomalies. The plan is to establish four or five key "buckets" or categories of issues to monitor over the first 30 days of the integration. ### **Developing a Centralized Credential Management Solution** To resolve the root cause of credential-related failures, a new internal tool is being developed. This system aims to become the single source of truth for account credentials, eliminating current conflicts and manual processes. - **Two-Component System:** The planned solution will feature a **Credential Validation** page that flags discrepancies (e.g., credentials existing in one system but not the other, or mismatched values) and a **Credential Management** page for making corrections. - **Ownership and Workflow:** Clear ownership must be assigned for resolving validation alerts. The resolution process will involve choosing which system's data is correct, marking accounts inactive, or updating credentials directly. - **Data Synchronization Challenge:** A major technical hurdle is ensuring any change made in the new tool is synchronized bidirectionally with the legacy DS and UBM systems to prevent the same discrepancies from reappearing. The long-term goal is to have all systems point to a single, logged credential table. ### **Managing the Reporting Backlog and Data Discrepancies** The proliferation of ad-hoc report requests is consuming excessive resources. The team decided on a strategy to halt new requests after fulfilling the current backlog to focus on fixing the underlying data issues the reports reveal. - **Consolidating Requests:** Nine specific reports are currently in the queue, including updates to the Combined Lab report, a new Arcadia-specific report, and requests from multiple stakeholders (Tim, Gary, Mary, Afton). - **Communication and Moratorium Plan:** An email will be sent to all stakeholders listing all active and pending report requests to create visibility into the total workload. The intent is to deliver these nine reports and then institute a three-month pause on new requests to dedicate effort to solving the core problems the reports highlight. - **Data Integrity Issue:** An immediate inconsistency was identified where the count of "late billing" data differs between the UBM and DS Power BI reports, despite supposedly drawing from the same sources. This discrepancy requires investigation to ensure report accuracy. ### **Miscellaneous Operational Items** Two ancillary topics were briefly addressed concerning internal processes and compliance. - **Disaster Recovery (DR) Testing:** The team is coordinating a mandatory DR test but is pushing back on testing the third-party Auth0 integration, arguing that an outage of this external service is beyond their control to remediate. The focus will be on testing internal application failover. - **Vendor Support List:** For operational clarity, a list needs to be maintained and exposed internally showing which vendors are supported by Arcadia versus those that will always require manual bill retrieval. This will help route tasks correctly within the operations team.

## Summary The meeting primarily focused on the operational status and ongoing challenges with the Ascension account, covering progress on electronic payment adoption, data integration with a new platform, and strategies for addressing client concerns. A secondary discussion involved similar issues with the Victra account, using it as a comparative benchmark. The core objective was to align on messaging and next steps for client communication and internal process improvement. ### Electronic Payment Conversion Progress for Ascension Significant progress has been made in converting payments from paper checks to electronic ACH transfers, though a notable batch of exceptions remains. - **Substantial electronic payment adoption:** For a recent payment cycle, 2,666 out of 3,020 accounts were paid electronically, representing nearly 90% adoption. This is framed as strong progress. - **Targeted resolution for remaining checks:** The 354 accounts that still required checks are being actively investigated. A process is underway to pull credentials for these specific accounts to identify which ones simply need credential updates versus those with more complex issues. - **Structured follow-up process:** For accounts lacking credentials, a team member will investigate the individual payment portals to determine the necessary information for conversion. This information will then be emailed individually to the client and loaded into the system attributes to prevent future issues. ### Unresolved Account and Credential Issues Beyond the bulk conversion effort, several specific operational hurdles were identified that are causing recurring problems and client questions. - **The "51 Accounts" issue:** A backlog of approximately 51 accounts requiring action is slowly decreasing. The delay is attributed partly to cryptic or outdated notes in the system, which create confusion on required actions, and partly to utility response times that are beyond direct control. - **Uncontrolled Virtual Account Creation:** A technical issue where the system creates new virtual accounts for existing customers if any data field (like meter or service type) varies between billing cycles. This makes it appear that accounts are missing or unlinked. - **Operational solution in place:** The current fix requires manual intervention by operators to ensure new virtual accounts are properly linked and have all necessary attributes copied over before processing. Two operators are currently dedicated to managing this queue for Ascension. ### Arcadia Integration and Data Migration Status The team is actively testing and implementing Arcadia as a new platform for managing Ascension account data and credentials, running it in parallel with existing processes. - **Credential testing phase:** Out of 2,310 credentials submitted to Arcadia, the platform is actively testing them. A known set of 18 vendors (affecting roughly 100 accounts) have consistently failing credentials that require cleanup. - **Extensive account data loaded:** The Arcadia dashboard shows data for 6,930 account-provider combinations, which includes all historical accounts found under the submitted credentials, not just active ones. - **Parallel processing established:** PDF bills from Ascension are being successfully pulled into the new system. The team is building a foundation for continuous, automated ingestion, with a full test batch scheduled for processing over a weekend to gauge system performance and timing. ### Broader Operational and Client Relationship Challenges Discussions extended to systemic issues impacting client satisfaction and the justification for current operational constraints. - **Handling client concerns about late fees and checks:** A strategy was discussed for responding to frequent client emails about late fees and disconnection notices. The proposed response is to consistently explain the root cause: bills are often pulled after the due date due to process timing, making lateness unavoidable. The focus should be on sharing the progress made on electronic conversion. - **Explanation for payment method inconsistency:** For cases where an account pays electronically one month but by check the next, reasons can include portal payment limits (requiring a split payment), credit balances, or missing credentials at the time of processing. Each case is investigated individually. - **Comparative performance:** It was noted that the current ~90% electronic payment rate for Ascension is considered strong, especially when compared to the historical performance of the previous provider, who did not use customer portals and likely had a higher check volume. ### Path Forward and Client Communication Strategy The meeting concluded with alignment on next steps and how to communicate progress and plans to the client. - **Cautious timeline for Arcadia transition:** While work is advanced, the team agreed not to commit to a firm, short-term deadline for fully transitioning Ascension to Arcadia. Instead, a runway of 30-60 days was suggested to work through challenges. - **Transparent and proactive communication:** The consensus was to maintain transparency with the primary client contact, providing detailed updates on electronic payment progress, the plan for residual check issues, and the work on Arcadia integration to build comfort and preempt internal pressures they may be facing. - **Decision point on manual processing:** A pending decision was noted regarding whether to manually process any new, urgent Ascension invoices outside of the new system during the transition, with a review planned for the following Monday based on the weekend's system test results.

## Summary The meeting centered on resolving critical discrepancies in late bill reporting data between systems, establishing dashboard priorities, addressing customer billing requests, and managing urgent client payment file terminations. ### Discrepancies in Late Bill Reports A significant discrepancy was identified between the number of late accounts reported in different systems, requiring immediate investigation and alignment. - **Data Mismatch Investigation:** The core issue is a major variance in the count of late bills for a specific client ("extension") between the "Data Services" system (showing 93 accounts) and the "UBM" system (reporting approximately 500 accounts). This large gap suggests potential problems with data synchronization, duplicate records, or differing definitions of "late." - **Clarifying Report Logic:** The report in question flags an invoice as "late" if it is not received by a calculated "expected date," which is based on the prior invoice cycle. The team needs to ensure this logic is consistently applied across all data sources. - **Defining Key Metrics:** There was a specific discussion about clarifying the "last payment date" field to avoid customer confusion. The team agreed it currently reflects when a payment was marked for processing in UBM, not necessarily when it cleared the bank, which is a crucial distinction for customer communications. - **Next Steps for Resolution:** The immediate action is to share and compare exported data sets from both systems to pinpoint the root cause of the discrepancy. The goal is to have a single, reliable source of truth for late account reporting. ### Prioritization of Dashboard Development The development of new reporting dashboards was discussed, with a clear directive on which project should receive immediate focus. - **Template-Based Dashboard as Priority:** The highest priority is given to building a dashboard that visualizes the metrics and calculations currently tracked in a specific Excel template. This dashboard will standardize the weekly reporting process for late bills and related metrics. - **Strategic Rationale for Priority:** This project was prioritized over other dashboard work because it directly supports the most critical and time-sensitive operational reviews, where data accuracy is currently under scrutiny. ### Customer Billing Requests and System Updates The conversation touched on standard customer service requests and the systems required to fulfill them. - **Paperless Billing Requirements:** A customer request to switch to paperless billing was reviewed. It was clarified that for customers to successfully go paperless, they typically need an active "Energy Manager" or "CEP" account, not just a profile in the UBM billing system. - **Account Cleanup Tasks:** Related work is in progress to clean up and reconcile customer account data for another client ("Ascension"), with a target to complete this work on the same day. ### Urgent Client Payment File Terminations An urgent operational issue was raised regarding several clients demanding an immediate stop to payment file generation. - **Immediate Deadline Pressure:** One client ("Facial") has demanded that payment files stop being generated, initially requesting an immediate halt. A compromise was reached to process any final transactions and then cease files by the end of the week. Other clients are expected to follow with similar requests. - **Operational Coordination Needs:** This creates a tight timeline requiring coordination between teams to: 1) clear any pending transactions in the system, 2) formally stop the automated file generation, and 3) allow the payment processor ("PayClearly") time to administratively close the linked bank accounts. The team emphasized the need for clear, confirmed deadlines from clients to execute this process smoothly. - **Contractual Implications:** The urgency is partly driven by a separate client ("URA") that has threatened contract termination if certain issues are not resolved by the end of the month, highlighting the broader business risk associated with billing and payment system problems.

## Overview of the EPIC and Development Approach The discussion centers on a new EPIC focused on data credential management, introduced for collaborative review and planning rather than as a finalized specification. The intent is to adopt an iterative and interactive development process, moving away from a linear "finish then review" model. This approach is designed to allow for continuous feedback and adjustments as the work progresses, ensuring alignment and addressing any overlooked requirements early on. ## Consolidating Credential Data from Multiple Sources A foundational requirement for the system is the ability to aggregate credential information from two distinct backend services: UBM and Data Services (DS). The architecture must be capable of pulling data from both systems to create a unified view for management and validation purposes. This integration is the first critical step in building a comprehensive credential management platform. ## Core Credential Comparison and Matching Logic The central operational logic involves comparing the credentials retrieved from the two source systems. The outcome of this comparison dictates the subsequent workflow: - **Matching Credentials:** When credentials from UBM and DS are identical, they should be automatically migrated to a new, designated table within the credential management interface. This signifies they are verified and ready for active management. - **Non-Matching Credentials:** Credentials that do not match between the two sources must remain within the credential validation queue. This discrepancy flags them for manual intervention and resolution. ## Managing Discrepancies and Required User Actions For credentials that fail the automatic matching process, a clear manual action workflow is necessary. Authorized personnel must be able to review each discrepancy and determine the correct resolution from a set of predefined actions: - **Validate Correct Source:** The user must decide whether the UBM credential or the DS credential is the correct and authoritative record. - **Invalidate and Remove:** The user should have the option to mark a credential as obsolete or incorrect and delete it entirely from the system. - **Other Remedial Actions:** The system should accommodate additional resolution paths as needed to handle edge cases or complex discrepancies. ## Synchronizing Changes Back to Source Systems A crucial final component of the workflow is bidirectional synchronization. After actions are taken within the management interface-such as validating a correct record or deleting an invalid one-these changes must be reliably propagated back to the respective original applications (UBM and DS). This ensures data consistency across the entire ecosystem and closes the loop on the credential management lifecycle.

## **Overview of the File Processing Project** The meeting centered on advancing a critical project to automate the ingestion of vendor invoice PDFs (specifically for Ascension) into the system. The immediate goal was to finalize and deploy a script that would rename and prepare approximately 1800 files for processing. A key dependency involved providing clear instructions and necessary data mappings to an external team member, Priyanka, to ensure files were correctly renamed before ingestion. The broader objective was to establish a standardized, automated pipeline that leverages existing invoice templates for efficient data extraction, moving away from manual and generic processing methods. ## **Naming Convention and Data Mapping Requirements** A core focus was defining and communicating the exact naming convention for the PDF files to enable automatic matching and processing. ### **Defining the Essential Data Points** The file names must encapsulate three critical pieces of information to be successfully matched against the internal database: the Client ID, Vendor ID, and Account Number. The **Client ID** for Ascension is a fixed, hard-coded value. The **Vendor ID** is unique to each vendor within the client's system, and Priyanka was confirmed to have access to this mapping from a previously shared spreadsheet. The **Account Number** must be the *non-cleaned* version, including spaces and dashes as they appear on the original documents, to ensure accurate matching even if the source system removes special characters. ### **Resolving Mapping and Access Issues** There was significant discussion around sourcing the correct **Vendor Code**, which is distinct from the Vendor ID and specific to the internal system (DS). It was determined that Priyanka likely does not have this information. The action was to export a list of existing vendor codes and IDs for Ascension and provide it to her. This list would serve as the authoritative mapping, ensuring she renames files using the correct identifiers from the internal system, not from intermediary Excel files. ### **Handling Temporal Data and Duplicates** The team anticipated a future challenge: multiple invoice files for the same account over time (e.g., from different months). To prevent overwrites and maintain a clear audit trail, it was agreed that **a timestamp or date must be incorporated into the file name or folder structure**. This ensures each unique bill version can be stored and processed independently. ## **File Transfer and Infrastructure Considerations** The current method of transferring large ZIP files (several gigabytes) via email was identified as a bottleneck. - **Current Process Limitations:** Downloading and re-uploading these large files is time-consuming and prone to delays, especially with potential VPN or bandwidth issues. This creates a risk if files need to be re-sent with corrected names overnight. - **Exploring Alternatives:** Solutions like using a dedicated **SharePoint folder** or setting up an **FTP location** were briefly discussed. These would allow for direct, programmatic file access and eliminate the manual email step. - **Decision for Immediate Action:** For the immediate task of processing the 1800 files, the team decided to continue with the email method to avoid investing time in new infrastructure. However, the need for a more robust, automated file transfer solution was acknowledged as a future improvement. ## **Script Development and Validation Logic** The development and logic of the processing script were scrutinized to ensure robust and correct operation. ### **Core Script Functionality** The script's primary task is to **rename the downloaded PDF files according to the established naming convention** and prepare them for upload into the DSS platform. There was a decision to potentially share the script directly with Priyanka for execution, though finalizing this was planned for the next day. ### **Implementing Critical Validation Guardrails** A paramount requirement was added to the script's logic: **strict validation before ingestion**. The script must check if the parsed Client ID, Vendor ID, and Account Number from a file name have a perfect match in the internal database. - **Successful Match:** Files that match proceed to the optimized ingestion flow where a specific invoice template is used to guide an LLM in data extraction. This is the desired, efficient path. - **Failed Match:** Files that do not match **must not be processed at all**. They should be logged and set aside. This prevents files from falling into a generic, manual review queue, which would create more work downstream and defeat the purpose of standardization. ### **Proactive Testing with Sample Data** To ensure the mapping logic works, the team agreed to test the script against a **sample of 2-3 actual PDFs** before full-scale execution. This would verify that the naming convention correctly extracts the necessary identifiers. ## **Future Process Enhancements and Metadata Tracking** Looking beyond the immediate task, the conversation touched on necessary enhancements for a sustainable, long-term process. ### **Managing Account Status Post-Upload** A follow-up step after uploading bills is to temporarily **"snooze" or pause the corresponding client accounts** for a few days. This is a precautionary measure to prevent duplicate processing until the team is confident the correct bills (e.g., the most recent by date) have been fully ingested. ### **The Imperative for Comprehensive Logging** The team emphasized the need for the script to generate **detailed metadata logs**. Each file processing event should record when it was fetched from the source (Arcadia), renamed, and ingested. - **Purpose of Logging:** This creates an audit trail and history for each invoice, moving away from relying on email or chat messages to reconstruct events. It allows the team to know precisely which data came from which export job and when. - **Enabling Advanced Operations:** Reliable metadata is foundational for future capabilities like **duplicate detection** and understanding the chronological sequence of bills for the same account, which is vital for accurate financial tracking and reporting.

## **Customer** The customer is a significant strategic partner, referred to as Simon, operating with complex financial systems. Their background involves a legacy relationship with a previous provider (Angie) and an internal reliance on specialized knowledge for Accounts Payable (AP) file generation and Enterprise Resource Planning (ERP) integration. The unexpected passing of a key internal engineer, Tom Barrett, who possessed critical, undocumented knowledge of their AP file specifications, has created a major internal knowledge gap and stalled their ability to provide necessary requirements. ## **Success** While the immediate context is focused on an active implementation challenge, the underlying product or service is designed to provide a critical financial consolidation and payment solution. The core value proposition is the ability to seamlessly pull funds from a designated bank account, pay bills on the customer's behalf, and deliver detailed AP files that integrate directly into their ERP system. This provides them with full financial visibility and accountability, transforming a simple bank withdrawal into a detailed, auditable record of exactly "who was paid what and when." ## **Challenge** The single biggest challenge is a critical and escalating delay in obtaining the precise technical specifications required to build the AP data files. This blockage stems directly from the loss of the key internal expert and has been compounded by repeated meeting cancellations, rescheduling, and a lack of empowered personnel on the customer's side to provide answers. This delay has compressed the project timeline to a critical point, jeopardizing the agreed "go-live" date. Furthermore, there is a recognized sensitivity around the transition from their former provider, adding layers of complexity to aligning deliverables and timelines. ## **Goals** The customer's primary goals are clear and time-sensitive: - To successfully launch the service and meet the April 1st (March 31st) deadline for the new payment cycle. - To receive accurate and customized AP files that can be ingested into their ERP system, providing the necessary financial reporting and audit trail. - To manage a smooth transition away from their previous provider, Angie, which may involve navigating a termination notice period. - To establish a reliable and accountable process for bill payments and financial consolidation through the new service.

## Summary ### Onboarding Process and Timeline Expectations The meeting focused heavily on reviewing and standardizing the customer onboarding process, with particular attention on timelines and required documentation. A key goal is to establish a clear and consistent **90-day rule for invoices**, ensuring that no invoice processed during onboarding is older than this threshold. The discussion revealed that while the current average onboarding time ranges from three to five months, there is an aspirational goal to reduce this to a **90-day average**. This duration includes customer dependencies like scheduling kickoff calls and gathering documentation, which can cause significant delays. - **Invoice Age Limitation:** A strict policy is being implemented where any invoice received that is over 90 days old cannot be processed. This necessitates close collaboration with the sales team to set correct expectations from the contract stage. - **Onboarding Timeline Analysis:** The team will create a detailed timetable to analyze how long it takes to onboard every 500 accounts. Historical data suggests past timelines were four to six months, partly due to prioritization of other projects. - **Tracking Customer-Caused Delays:** A significant pain point identified is the inability to easily track and attribute timeline extensions to client-side delays (e.g., rescheduling, slow responses). The team discussed leveraging HubSpot or existing CSM pipelines to log these reasons systematically, creating a defensible audit trail. ### Invoice Data Management and Cleanup A major operational challenge discussed is the management and cleanup of account and invoice data across platforms (UBM and Data Services). Discrepancies and duplicate accounts are causing inaccuracies in critical reports like the missing bills report. - **Simplifying the Missing Bills Report:** The plan is to create a simplified, actionable report that lists accounts, their last actual bill date, and excludes mock bills, moving away from overly complex calculations that have caused issues. - **Systematic Account Cleanup:** A weekly review process is required to clean up duplicate and erroneous accounts. This is not a one-time fix but an ongoing operational necessity. - **Preventing Future Data Issues:** For new bills processed through DSS, there will be an effort to tag entries created by the system. This will allow for periodic bulk cleanup of any erroneous lines it generates, acting as a stopgap until more robust validation guardrails are built into the system. ### Credential Management and Platform Integration The team is working towards a "single source of truth" for customer credentials, which are currently stored in multiple disparate systems. This is part of a broader effort to standardize and link data across platforms. - **Centralizing Credentials:** A primary action item is to chart all current locations where credentials are stored and work towards consolidating them into one authoritative system. - **Standardizing Account Linking:** The process for linking billing accounts and locations between Data Services and UBM is being reviewed to ensure consistency and accuracy. - **Automation on the Horizon:** Future automation efforts are planned to extract invoice data via scanning technology, reducing manual entry and speeding up the onboarding process. ### HubSpot Implementation for Ticket Management The rollout of HubSpot as a centralized issue-tracking system is imminent, marking a shift away from managing requests and problems via email. - **Internal Rollout First:** The system will be launched internally for the team for a testing period of two weeks to a month before being made available to customers. - **Structured Workflow:** The goal is to have all internal and eventually customer-issued tickets flow through HubSpot, improving visibility, tracking, and ensuring no request is lost. Customer Support Managers (CSMs) will be the primary point of contact for tickets. - **Training and Materials:** Training is being organized, and the creation of instructional videos is in progress to facilitate adoption across the team. ### Standardizing Customer Communication and Requests The team identified a need to clean up and standardize communication channels, particularly email distribution lists, and to enforce consistent processes for customer requests like adding new locations. - **Distribution List Cleanup:** Multiple overlapping distribution lists (e.g., for CS, operations) have become cluttered. An action is in place to audit all lists, remove inactive members, and define clear purposes for each to prevent emails from being ignored. - **Process for New Locations/Accounts:** A standardized procedure was reiterated: customers must work with their CSM to add new locations to a central tracking document (e.g., a SmartSheet), the CSM must then add it to UBM, and finally tag the data services team to enroll it. This ensures billing, credential setup, and platform updates happen in sync. - **Reinforcing Official Channels:** The team plans to reinforce with clients the mandatory use of official distribution lists or the future HubSpot ticket system for all requests, especially urgent matters like disconnections, to ensure they are seen and acted upon promptly. ### SmartSheet Usage and Process Standardization A significant portion of the meeting debated the role and format of SmartSheets used in customer onboarding and account management. The current inconsistent use is creating operational inefficiencies. - **Inconsistent Implementation:** Currently, SmartSheets are used differently by each CSM and customer. Some clients actively use them, while others refuse, and the sheet format often gets customized per client request, breaking standardization. - **Desire for Integration and Enforcement:** There is a strong desire to lock down a standard SmartSheet format and, ideally, integrate it directly within the UBM platform. This would make it the single, live source of truth for billing account lists and attributes, visible to all stakeholders without manual cross-referencing. - **Shifting the Paradigm:** The discussion highlighted a need to move from a flexible, service-oriented model to a more productized one. The team recognized the inefficiency of constantly adapting to unique client requests and the need to establish and enforce standard operating procedures for data exchange.

## Customer The customer is a large enterprise managing utility accounts, likely in the energy or facilities management sector. They have transitioned from a previous bill pay supplier and are now engaged in a complex onboarding process involving thousands of utility accounts. Their background indicates a need for robust, automated solutions for invoice processing, bill payment, and data reporting to manage a high volume of transactions across multiple utilities and locations. ## Success The most significant achievement highlighted is the successful integration and processing capability for a high volume of utility invoices through the platform. A key success is the operational setup for **bill pay functionality**, particularly the handoff to a payment processor. The system demonstrates the ability to map accounts, send payment files, and facilitate electronic payments, which is foundational to the customer's core operational efficiency. Furthermore, the discussion around creating **standardized AP file templates** points to progress in automating financial reporting, which is a major value driver for enterprise clients seeking to streamline their accounts payable processes. ## Challenge The primary and most pressing challenge is the **excessively long and inconsistent onboarding timeline**, currently averaging around five months from contract execution. This is well above the industry average and is a major point of friction. The process is hampered by several interconnected issues: - **Data and Credential Management:** A lack of a single "source of truth" for account credentials leads to discrepancies between systems. Credentials are stored and updated in multiple places (e.g., SmartSheets, Data Services, UBM), causing sync issues and manual workarounds. - **Onboarding Process Complexity:** The initial onboarding template is considered overly burdensome by customers, requesting too much information upfront and creating a poor first impression. There is no clear, phased approach for collecting essential versus "nice-to-have" data. - **Internal Coordination Gaps:** There is confusion and inconsistency in handoffs between teams (Sales, Customer Success, Data Services, Onboarding). This leads to missed requirements, late discovery of issues (like needing EDI bills instead of portal access), and a lack of clear ownership for tracking credential updates from customers. - **Account Reconciliation:** Discrepancies in the total number of active accounts between different internal systems (UBM vs. Data Services) create reporting inaccuracies and operational confusion. This is exacerbated by the system's creation of "virtual accounts" for EDI bills and a lack of automated processes for closing finalized accounts across all platforms. ## Goals The conversation reveals several clear customer goals that the service aims to fulfill: 1. **Reduce Onboarding Time:** Dramatically shorten the onboarding cycle from the current five-month average to be more competitive, ideally aligning with or beating the industry standard. 2. **Achieve End-to-End Automation:** Fully automate the bill upload, processing, and payment workflow. This includes the ability to automatically scan and validate invoice dates, extract account data, and sync credentials seamlessly between all systems. 3. **Gain Clear Visibility and Reporting:** Have accurate, real-time visibility into their account portfolio, processing status, and performance metrics (SLAs). They need a single, reliable source for account counts and processing timelines to support their own internal reporting and financial close processes. 4. **Streamline Credential Management:** Implement a unified, automated system for managing and updating utility website credentials to ensure bill pulls are successful and payment information is always current. 5. **Simplify the User Experience:** Move towards a more customer-friendly onboarding process where they can simply provide invoices or a credential, and the system handles the rest, as opposed to manually filling out extensive spreadsheets.

## **Invoice Processing Status and Urgent Backlogs** The meeting opened with a critical review of invoice processing volumes, revealing significant backlogs across major customer accounts. The data, current as of the previous afternoon, showed a mixed picture with many invoices not yet processed. Specifically, there were 53 invoices for one customer, with nine already past due, and another had over 2,000 invoices with only about 1,000 processed month-to-date. This highlighted a pressing capacity issue, as the team is falling behind on the volume of invoices received, risking service level agreements and customer satisfaction. ## **Critical Gaps in Reporting and Dashboard Visibility** A major discussion point was the inadequacy of current Power BI reports for tracking progress, which currently only filter by the date an invoice was created in the system. - **Need for invoice date filtering:** It was stressed that reports must also allow filtering by the actual invoice date to accurately reflect processing performance and customer billing cycles. A ticket needs to be created to address this gap. - **Creating a unified operations dashboard:** There is a high-priority initiative to transform manually compiled spreadsheets into a live, comprehensive dashboard. This dashboard must cover all customers and service types, providing a daily, at-a-glance view of processing status for the entire team. - **Focus on underlying data transparency:** A key principle established was that while the dashboard is for monitoring, everyone must understand the source data and calculations behind it. This ensures the team can troubleshoot discrepancies, answer questions authoritatively, and manually pull data if the dashboard has technical limitations. ## **Systemic Issues: Broken Batches and Data Black Holes** The conversation identified several systemic risks in the data pipeline causing invoices to go missing or get stuck. - **Ongoing broken batch problems:** The number of "broken batches" - where invoice files fail to import correctly - has increased again. While a refactor of the underlying system is nearing completion to mitigate this, it remains a concern. - **Nervousness around invisible failures:** There is significant anxiety about invoices disappearing into a "black hole" where they are output from one system but never appear in the processing queue. Historical instances where over 160 invoices were lost were cited, emphasizing the need for better visibility and tracking to prevent customer complaints about missing invoices. ## **Downstream Impact: Bill Payment File Errors** A surge in bill payment file errors was analyzed, traced back to incomplete setup during invoice processing. - **Root cause in virtual account attributes:** Many errors occur because required virtual account attributes (like specific bank account codes) are missing. This is often because the information was never provided by the customer during onboarding or wasn't properly added to the master data sheet. - **Training and process gap:** A serious concern was raised that operators processing invoices may not be adequately trained or diligent in linking invoices and verifying all required attributes. This creates a domino effect, where an invoice is processed but then fails at the payment stage, causing further delays and requiring manual intervention from customer success or other teams to resolve. ## **Manual Payment Bottlenecks and Credential Issues** The status of manual check payments was reviewed, with a focus on reducing reliance on this slow method. - **Outstanding check payments:** There are 17 checks pending for two high-priority customers, with efforts underway to convert them to electronic payments. Another customer has 26 checks pending, primarily due to persistent credential issues preventing electronic payment setup. - **Priority and escalation:** The strategy is to resolve the electronic payment setup for the two main customers first, then tackle the credential issues with the other. This is critical because manual checks inherently slow down the payment cycle. ## **Resource Allocation and Contractor Management** The discussion concluded with a focus on optimizing the contractor workforce to address the identified operational gaps. - **Need for clear resource mapping:** There is a lack of clarity on where contracted resources are currently allocated and what specific tasks they are performing. A directive was given to compile a list detailing each contractor's primary focus area (e.g., downloads, data entry, outreach). - **Ensuring productivity and proper placement:** The goal is to audit whether contractors are effectively utilized and to strategically reallocate resources if necessary. The intent is to ensure that all available personnel are deployed to the highest-priority tasks, such as clearing invoice backlogs or managing download queues, rather than having underutilized capacity.

## **Current State and Goals for Arcadia Integration** The meeting primarily focused on the ongoing integration of the Arcadia system for automated bill retrieval, with a specific and urgent emphasis on the Ascension account. The core goal is to establish a reliable, automated pipeline to replace or augment the current manual processes. To achieve this, the discussion centered on understanding the existing setup, defining the necessary technical steps for a functional prototype, and identifying the broader system impacts to ensure a smooth transition. ### **Existing Prototype Setup & Immediate Actions** The current proof-of-concept uses a local PHP script to process bills. The immediate plan is to enhance this prototype into a more robust staging solution before full production integration. - **Local Script Process:** A PHP script running on a developer's machine ingests a CSV file of account data. It uses provided API tokens to call Arcadia's credentials endpoint and, if access is granted, fetches PDFs which are then stored locally in a designated directory. This serves as a complete end-to-end test. - **Enhancements for Staging:** The focus is on moving this process from a local machine to a server environment. This involves connecting the script directly to a database for credentials and modifying the output to drop PDFs into a new, dedicated directory that mimics a production landing zone. Additional logging for API calls (who made them, when, and the response) is also a priority for traceability. - **Naming Convention Definition:** A critical next step is to finalize and communicate a strict file naming convention for the PDFs retrieved by Arcadia. This convention must reliably encode the client, vendor, and account number to allow downstream systems to parse and process the files correctly, even if existing manual processes do not consistently follow such standards. ### **System Reports & Data Tracking** A significant part of the discussion involved understanding how current operational reports would be affected by the Arcadia integration, ensuring that automatic retrieval doesn't create gaps in visibility. - **Understanding the Lab Report:** The primary tool for tracking invoice status is the "lab" report, a Power BI dashboard that combines data from UBM and Data Services (DS). It shows the last invoice date received for each client-vendor-account combination and the projected date for the next invoice, highlighting accounts that are late. - **Impact of Arcadia Integration:** The key insight is that Arcadia does not directly update these reports. Instead, the reports rely on data updated by downstream systems. When an Arcadia-retrieved PDF is processed through the standard Data Services (DSS) pipeline-just like a manually downloaded bill-it will automatically update the "last invoice date" in the system. Therefore, successful DSS processing is the critical link for Arcadia to reflect correctly in all operational reports and task lists. ### **Duplicate Invoice Handling** The conversation clarified the existing multi-layered system for preventing duplicate invoices, which Arcadia-sourced bills must seamlessly integrate with. - **Checksum at Ingestion:** The first automated check occurs the moment a PDF is uploaded. The system generates a checksum (a digital fingerprint) of the file and compares it to existing records. If an identical file has already been processed, it is rejected immediately as a duplicate. - **Business Logic in DSS:** A second, more nuanced check happens during DSS processing. If the key fields of a bill-client, vendor, account number, service period, and amount due-match an existing invoice, DSS will flag it as a potential duplicate for human review, even if the PDF files themselves are different (e.g., a web download vs. a scanned copy). - **Implication for Arcadia Testing:** This means that for the initial January bill run, there will likely be significant overlap with manually retrieved bills. The system's duplicate handling is designed to manage this, allowing the team to test the Arcadia flow without necessarily disrupting the existing manual workflow for the same period. ### **Task Management & Workflow Automation** A major operational question addressed was how the automatic population of bills via Arcadia would interact with the manual task system for bill retrievers. - **The Core Challenge:** The FDG Connect system generates tasks for operators based on invoice cycles. If Arcadia automatically delivers a bill, the corresponding manual task should ideally be dismissed to avoid redundant work. - **Proposed Solution:** The prerequisite for automating task dismissal is the reliable identification of the client, vendor, and account number from the Arcadia-sourced PDFs (via the naming convention). Once this is achieved and the bill is successfully processed through DSS, the system should be able to automatically dismiss the related task for that billing cycle. - **Transition & Webhooks:** The discussion looked ahead to moving from one-off "batch" retrievals to a continuous, automated process. The future state involves setting up webhooks with Arcadia so that when a new bill is available, it is pushed automatically, starting a new 30-day cycle for the next expected invoice, thereby creating a fully automated pipeline. ### **Broader Project Context & SOC 2 Preparation** The meeting concluded with a brief alignment on other important initiatives, particularly the upcoming SOC 2 compliance audit. - **Prioritization of Arcadia:** The integration work, especially for Ascension and a few other key customers, is the top technical priority for the immediate timeline, with the goal of having a solid handle on the process by the end of the month. - **Efficient SOC 2 Collaboration:** To avoid the time-intensive meeting-heavy approach of past audits, the plan for the upcoming SOC 2 (and SOC 1) work with Eden Data is to establish a clear, asynchronous collaboration model. The intent is to have a single point of contact manage requests via Slack or tickets, providing detailed, actionable tasks to engineers (like Dan and Jay) without requiring them to be on frequent calls, thus minimizing disruption to development workflows.

## **Current State and Objective of Arcadia Integration** The meeting focused on accelerating the integration of Arcadia, a third-party provider, into the existing bill processing pipeline. The primary goal is to leverage Arcadia to automatically download and process bills for the Ascension client, thereby circumventing the slower, manual process currently handled by operators using the Web Downloader Helper. There are approximately 1,800 credentials (bill sources) ready for processing from Arcadia, with the ultimate aim of moving vendor bill retrieval away from internal tools and towards more robust third-party providers. The discussion centered on three key pillars: tracking the source of bills, automating the new workflow, and building foundational reports. ## **The Challenge of Source Tracking and Differentiation** A core technical requirement identified is the ability to distinguish bills sourced from Arcadia from those coming through other channels, such as the internal Web Downloader Helper or another third party like BDE. Currently, files from BDE enter the system without clear source tagging, simply appearing via a file watcher. For Arcadia, it is crucial to implement a method to tag these files upon ingestion into the system to enable accurate tracking, reporting, and process auditing. The proposed solution is to assign a dedicated system user (e.g., "Arcadia") to all bills uploaded through this new channel, which would be reflected in the `created_by` column of the database, unlike the current empty user field for file-watcher imports. ## **Credential Management and Data Mapping** A significant prerequisite for automation is the secure storage and management of client credentials used by Arcadia to access billing portals. These credentials are specific to each client account and include vital metadata such as the client account number, client name, and vendor. A new database table needs to be created to store this information, mapped to existing client and vendor records within the system. This mapping is essential because, when a bill is downloaded, the system must use the account number from Arcadia to look up the corresponding internal Client ID and Vendor ID. This information is then passed to the document processing service (DSS) during upload to ensure the bill is correctly associated. ## **Designing the Automation Service Architecture** The conversation explored the technical design of the service that will interact with Arcadia. The envisioned service would utilize the new credential table to retrieve access details for client accounts. It would then call the Arcadia API to download PDF bills. For each successful download, the service would subsequently call the DSS upload API, passing the PDF along with the mapped client and vendor identifiers. The design explicitly avoids using a separate FTP folder or file-watcher setup for this new source; instead, it aims for a more direct, service-to-service integration that pushes files into the processing queue with the correct "Arcadia" source tag. ## **Immediate Next Steps and Path Forward** To maintain momentum, immediate action was emphasized. The team plans to spend time detailing the service setup. The initial, non-automated flow involves using a CSV file of credentials, which can be sent to Arcadia to retrieve a batch of PDFs. These PDFs can then be used for initial testing to verify the upload and client-matching logic before the full automated service is built. The focus for the current week is to make tangible progress on both the credential management system and the service design to hand off clear tasks to the development team.

## Summary The meeting focused on operational coordination and task planning. ### Coordination with Jake and Offshore Team A key action was to connect with Jake to receive and relay necessary instructions. This coordination is critical for ensuring alignment on task execution and priorities. ### Offshore Team Schedule and Availability The Offshore team's upcoming reduced availability was noted, as they will be working a half day on the following day and will be entirely off on Wednesday. This information is essential for planning deadlines and managing workload expectations to avoid delays. ### Planning for Arcadia Setup Discussion A follow-up discussion was scheduled to talk through the setup process for Arcadia. The timing for this conversation was left open, with a request to confirm availability later in the day to solidify the plan.

## Summary The meeting centered on addressing critical issues with how missing utility bills are reported to customers, with a particular focus on the problematic inclusion of internally created "mock" bills in these reports. The discussion involved analyzing the shortcomings of existing reporting tools and defining the requirements for a new, streamlined solution. ### Problem Statement: Inaccurate "Missing Bills" Reporting The core problem is that customers receive reports listing bills as "missing" when the company has actually created placeholder mock bills internally. This creates unnecessary concern and extra manual work for customer support teams who must investigate these false positives. - **Mock bills are misleading customers:** The current logic in reports like the "LAD report" or "billing accounts report" does not distinguish between truly missing bills and those where a mock bill has been created as a temporary placeholder. Customers see these as gaps in service, leading to repeated inquiries and eroding trust. - **Underlying data inconsistencies compound the issue:** Problems with account number formats (flipped numbers, extra spaces) create duplicate accounts in the system. Furthermore, delays in data synchronization between the UBM platform and the Data Services (DS) backend mean a bill might be "in house" but not yet visible to the customer, incorrectly flagging it as missing. ### Analysis of Current Reporting Tools Existing reports were deemed insufficient or too complex for solving the immediate problem, as they are built on flawed or overly intricate logic. - **The "Bill Health" or "LAD" report has fundamental issues:** While its logic for calculating invoice due dates and lateness works, it suffers from underlying data cleanup problems. The report's complexity, with multiple tabs and calculations, is designed for manual operational analysis, not for providing a clear, customer-facing status on missing *actual* invoices. - **A cleanup effort is inevitable but separate:** It was acknowledged that a broader data cleanup initiative for the entire platform is upcoming and necessary, as signaled by impending audits from clients like PPG. However, this is a distinct, larger project from the immediate need for an accurate missing bills report. ### Defining Requirements for a New Solution The primary goal is to create a new, focused report that provides a single source of truth for customers regarding genuinely missing bills. - **Core deliverable: A "Missing Bills" report:** The group agreed to name the new output simply the "Missing Bills" report to avoid confusion with existing tools. Its sole purpose is to show when the last *actual* (non-mock) invoice was received for a given account. - **Key data points for the new report:** The report should include essential utility information like location name, commodity type, and account number to be actionable. Crucially, it must **exclude all mock bills** from its calculations. - **Simplified logic is preferred:** The proposal is to build a new report from underlying data sources rather than trying to fix the complex LAD report. This new report would forego complex latency calculations in favor of showing the last received invoice date, providing a clearer picture. ### Technical Considerations and Implementation Plan The discussion turned to the feasibility of building the new report, identifying available data points and potential hurdles. - **Mock bills are technically filterable:** A key technical insight was that all mock bills created within the UBM platform have a specific flag that can be used to exclude them from queries. This makes the primary requirement technically achievable without deep changes to existing report logic. - **Challenges with data reconciliation:** A proposed shortcut-automatically considering any account in UBM but not in Data Services as invalid-was rejected as too risky. Without manual diagnosis, there's no guarantee these represent errors rather than simple synchronization delays or setup oversights. - **Scope limitations are clear:** The new report will not solve perennial data issues like duplicate accounts caused by formatting errors. Identifying and cleaning these duplicates remains a manual operational task outside the scope of this development work. ### Next Steps and Prioritization The conversation concluded with an outline of immediate actions and a recognition of competing priorities. - **Immediate action is to design the query:** The plan is to review existing data pull instructions, incorporate the step to filter out mock bills using their flag, and design a coherent query for the new report. This design work is the immediate next step. - **Development must be prioritized among other tasks:** The engineering work for the Missing Bills report will need to be queued alongside other critical items, including performance improvements for Power BI and issues related to a separate system called Ascension. The report is urgent but not the only technical priority. - **Acknowledgment of resource constraints:** There was a clear understanding that solving the root causes (like data synchronization and cleanup) would require more than just a new report, potentially involving other teams, but current resources are limited. The new report is seen as a crucial stopgap to alleviate immediate customer pressure.

## Summary This meeting centered on the integration of a new data retrieval service, Arcadia, focusing on operational processes, client selection, and the development of necessary tracking systems. Key challenges around credential management, data synchronization, and reporting visibility were discussed in depth to ensure a successful rollout. ### Credential Management and Data Synchronization This section detailed the complex process of handling login credentials when using the Arcadia service, highlighting the need for clear procedures to correct failures and synchronize data across systems. A primary distinction was made between two products: the "plug" service and "credential management." For the plug service, the workflow involves receiving a report of failed credential attempts (e.g., 15 out of 185), which are then fixed and resent. When credential management is involved, a more collaborative, conversational process with the client is required to resolve bad credentials managed on their end. The core challenge is defining clear responsibility lines ("swim lanes") for fixing credentials between the internal team and the client. - **Centralized System for Correction:** A major operational gap was identified: the current use of Excel for tracking credential corrections is unsustainable. The immediate need is for a centralized system to log Arcadia API calls, timestamp corrections, and document which credentials were validated as correct for each customer. This system is essential for auditing and ensuring fixes are applied consistently. - **Resolving Data Conflicts:** A significant technical hurdle involves discrepancies between credentials stored in the UBM system and the Data Services (DS) system. Since syncs are not real-time, the systems cannot autonomously determine which credential is correct when they disagree. The proposed solution involves identifying duplicates and then requiring manual human review to establish a single source of truth. A future state would involve a single, third credential table that all applications point to, but an interim validated table within the DS app is planned. - **Initial Workload Concerns:** It was acknowledged that initially, cleaning up credential discrepancies could be a substantial, time-consuming task, especially with a high failure rate at launch. The hope is that after a significant initial cleanup, the volume of weekly discrepancies will trend downward. ### Client Selection for Initial Arcadia Rollout The discussion evaluated which clients should be part of the initial, phased rollout of the Arcadia integration, balancing risk and operational learning. There was strong concern about including a high-profile, problematic client ("Victor") in the first phase, as any integration issues could exacerbate an already tense relationship. The consensus was to start with smaller, more manageable clients to allow the team to adjust and correct anomalies with less visibility and pressure. - **Recommended Initial Clients:** Three clients were selected for the initial rollout: Park, PNB, and Medline. Medline was noted as a good candidate because their credentials had recently been validated and were confirmed to be working. Jacobs was designated as the next candidate following these three. - **Rationale for Phased Approach:** This cautious approach allows the weekly steering committee to reassess progress and readiness before escalating to larger or more complex clients. The team is proceeding with setting up these initial clients for the Arcadia pull. ### Tracking and Reporting for Arcadia Data Retrieval A critical requirement identified was the need for a real-time tracking dashboard to monitor the success of Arcadia data pulls, moving away from unreliable, manual checks across multiple systems. The goal is to create a client-level tracker that shows, for a given month, the universe of accounts, which ones have been requested from Arcadia, and which have been successfully received. This provides visibility into what is still "missing" at any point during the month, not just at the period's end. - **Data Aggregation Challenge:** The tracking logic must account for Arcadia's operational model: they pull data at the credential level, not the account level, and return data for all accounts under that credential. This can result in multiple API calls and potentially multiple PDFs for a single account. The proposed view needs to roll up this activity to answer a simple question per account: "Did we get it this month?" - **Handling Unmatched Data:** A related issue is that Arcadia may pull data for accounts not under management with the client (e.g., 10 accounts on a utility site, but only 7 are contracted). These unmatched PDFs would go into a separate folder. A significant business concern is being charged for processing these successful but unnecessary PDFs. A future "preview" API endpoint from Arcadia could help selectively pull only needed accounts, but this is not currently available. - **Urgency for a Solution:** With an initial pull of 1800 accounts already executed, the necessity for such a tracker is immediate. The team cannot rely on piecing together information from multiple legacy systems (DS Lab, UBM Lab, etc.) to answer client inquiries about missing invoices. The new tracker must provide a clear, authoritative status for each account.

## Summary The meeting covered a range of operational topics, focusing on current data issues, the planning of upcoming procedures, team responsibilities, and resource allocation. The conversation was centered on improving processes and clarity to address ongoing challenges and prepare for organizational changes. ### Current Data Processing and Cleanup A significant portion of the discussion was dedicated to ongoing data cleanup efforts and processing issues with specific vendors and customer accounts. - **Pending Bills and Data Validation:** There are several batches of bills from specific dates still pending in "data valid verification," with suspicions that a bulk update attempt may have caused them to fail. The need for cleanup is emphasized to prevent future escalations. - **Targeted Cleanup for Specific Accounts:** Efforts are underway to reprocess bills for certain customers after reinstating validations, mirroring a previous cleanup process done for another account. This indicates a proactive approach to correcting data integrity for impacted clients. - **Tracking and Accountability:** There is a focus on identifying who is responsible for reviewing and resolving these lingering data issues, particularly for a specific park account, to ensure accountability and progress. ### SOP Meeting and Process Standardization Planning for an upcoming Standard Operating Procedures (SOP) meeting was a key agenda item, with several critical areas identified for documentation and alignment. - **Primary Focus Areas for SOPs:** The meeting will concentrate heavily on standardizing the **onboarding process** and establishing clear procedures for **leadership reports and metric reviews**. The goal is to create repeatable, documented processes for these core activities. - **Including New Workflows:** There was agreement to add discussions about the workflow for tasks being transitioned to Arcadia, specifically to clarify the process flow, flag logic, and expectations to eliminate team-wide confusion. - **Additional Process Documentation:** The need for an SOP related to invoice processing SLAs (Service Level Agreements) was also noted, highlighting a desire to formalize timing and expectations across various operational tasks. ### Metrics, Reporting, and Customer Communication Improving the accuracy and automation of metrics was discussed as a priority to meet leadership demands and enhance internal visibility. - **Automating Manual Reports:** A plan was set to take over the manual, weekly reports currently run by team members and build them into an automated Business Intelligence (BI) dashboard. This will save significant time and provide daily visibility into key performance indicators. - **Driving Factors for Reporting:** The push for better "missing bill" tracking and reporting is directly linked to current operational problems, as customers are now demanding more transparency due to these issues. - **Progress on Dashboard Development:** Encouraging progress was reported on the systematic pulling and visualization of metrics, which is expected to soon replace the need for manual report compilation. ### Team Structure, Handoffs, and Accountability Clarifying team responsibilities, especially during customer onboarding and transitions, was a major point of concern to prevent tasks from being dropped. - **Ownership of Credential Acquisition:** A clear issue was identified where team members assisting with obtaining utility credentials during onboarding were stopping work once a customer went "live," leading to dropped tasks. It was stressed that onboarding ownership continues until credentials are fully secured, and handoffs require explicit communication. - **Utility Outreach Team Capacity:** It was acknowledged that there isn't a robust, dedicated utility outreach team, so tasks cannot simply be dumped onto a non-existent group. Accountability must remain with the team that started the work. - **Coordination with Rebates Team:** Challenges in tracking progress were noted when members of the rebates team intermittently assist with tasks, as their primary duties can pull them away, creating blind spots in the process. ### Onboarding, Training, and Resource Allocation The discussion turned to leveraging new resources and refining training to address operational bottlenecks and improve process execution. - **Utilizing New Co-op and Contractor Resources:** With new co-op students and contractors becoming available, there was a strategy to potentially assign them to work on the complete and proper "lab" (likely a training or quality assurance environment) process, which has been difficult to maintain. - **Strategic Cleanup Priorities:** A directive was given to avoid spending time cleaning up data for a specific problematic customer ("Bandit") that is expected to churn soon, and to instead focus cleanup efforts on other accounts to maximize resource efficiency. - **Clarifying Roles for Support Staff:** Questions were raised about the current assignments of support staff, indicating some ambiguity in the division of labor between tasks like data downloads and utility outreach components.

## Summary The meeting covered a wide range of critical operational and technical initiatives, from urgent infrastructure migration and credential system overhauls to the integration of new automation services and addressing persistent process bottlenecks. The core theme centered on moving from reactive, manual fixes to building scalable, automated solutions that provide full visibility into data flows and system states. ### Urgent Cloud Infrastructure Migration A pressing priority is the immediate migration to Azure to alleviate severe operational and compliance burdens. The current on-premises environment has become unsustainable, creating significant overhead in managing infrastructure, vendor security, and compliance reporting. A recent incident involving false positives in a network penetration test report, which was incorrectly shared with a potential customer, highlighted the risks and wasted resources associated with the current setup. The migration to a managed cloud service (Constellation) is seen as essential to offload these challenges and prevent future, time-consuming fire drills. ### Overhaul of Credential Management and Validation Establishing a single source of truth for customer credentials is a foundational project to resolve chronic data issues. Currently, credentials are stored disparately across systems like UBM and DSS, leading to mismatches, manual reconciliation, and failed automated processes. The plan involves three key phases: first, a cleanup of existing credential data; second, the development of a unified interface within DSS to view and manage credentials by customer, vendor, and account; and third, ensuring all systems point to this single credential table. A dedicated "credential validation" view is also planned to instantly flag discrepancies between systems, which will be crucial for ongoing maintenance and support. ### Arcadia Integration for Automated Bill Retrieval Integrating the Arcadia service to automate PDF bill retrieval from vendor portals is a major automation initiative. While initial tests are promising, significant architectural considerations must be addressed to ensure reliability and auditability. Key requirements include creating a robust link between the Arcadia API request/response and the specific client-vendor-account it belongs to, establishing a DSUBM vendor crosswalk, and ensuring the entire chain-from credential used to the final processed bill-is fully traceable. Initially, the focus will be on processing Arcadia-retrieved PDFs through the existing DSS pipeline, postponing a direct JSON integration to avoid introducing new quality assurance complexities prematurely. ### Standardization with Build Templates and AI Processing Leveraging and cleaning up "build templates" is critical for standardizing bill processing and reducing error rates. A live system now uses these templates to guide AI (LLM) processing, providing consistent instructions based on customer-vendor-account setups. However, a cleanup of approximately 60,000 legacy line items is required, and a gap remains for roughly 20% of bills (e.g., from BDE or email) that lack the necessary metadata to map to a template. The long-term vision is a self-service model where issues can be traced directly back to the build template setup, shifting the focus from fixing individual bills to correcting root configuration issues. ### Operational Challenges and Team Process Alignment Internal operational inefficiencies and communication gaps are creating significant drag. Examples include cumbersome, manual email-based workflows for simple client updates that should be automated in the UI, and developers working on features with zero user adoption. There is a strong need to better define roles and expectations, particularly in communication for remote work, and to prevent system-level personnel from being pulled into individual bill-level support tasks. A strategic shift is needed to empower customer-facing teams with better tools and visibility, allowing technical teams to focus on systemic product fixes rather than reactive firefighting.

## **Customer** The customer is an energy management company operating under the Constellation brand, with a dedicated team (Navigator) handling customer success and operations. Their core function involves managing and paying utility bills for their commercial clients. This requires establishing and maintaining thousands of online credentials (usernames/passwords) with various utility providers to electronically access billing statements and account data. Their operations team is responsible for the initial setup and ongoing maintenance of these credentials, which is a complex and resource-intensive process. ## **Success** The most significant success achieved with the service is the strategic decision to offload the entire burden of credential management. By transitioning this function, the customer can eliminate the substantial internal effort and cost associated with setting up new utility accounts, troubleshooting login failures, and managing multi-factor authentication (MFA) challenges. The service will provide a dedicated, managed instance to handle the enrollment and continuous health monitoring of up to 7,000 credentials. This shift allows the customer's team to re-focus their efforts on higher-value activities related to their core business of customer service and payment operations, rather than on the technical minutiae of utility website integrations. ## **Challenge** The primary challenge centers on the initial onboarding and data transition process. The customer's existing credential data is often incomplete, lacking fields like phone numbers which are sometimes required by utilities for verification, creating a potential bottleneck for enrollment. Furthermore, handling Multi-Factor Authentication (MFA) for existing accounts presents a complex hurdle. For credentials they currently manage, resolving MFA may require cumbersome coordination with end-clients to receive codes or a lengthy process to change the authentication method to one the service can control. The challenge is to navigate these provider-specific MFA landscapes and data gaps efficiently to minimize delays in bringing accounts live on the new managed platform. ## **Goals** The customer's key goals for this engagement are clearly defined: - To successfully onboard an initial batch of approximately 2,900 active credentials from a specific client into the managed service as a first phase. - To ultimately migrate a total of up to 7,000 credentials to the service for ongoing management and maintenance. - To establish a transparent and frequent (initially weekly) reporting cadence to track the status of credential enrollment, identify any issues requiring their action, and understand the reasons for delays. - To gain real-time visibility into credential status, either through shared tracking documents or API access, to inform their own internal operations and billing workflows. - To achieve a seamless technical integration where they can reliably pull utility statement data via API from the new managed instance, just as they do from their current platform.

## Customer The customer is a large university with a complex utility management structure, operating multiple physical locations. They have numerous individual meters for electricity consumption across their campus, but these are consolidated into a single, large summary bill from their utility provider. Their background indicates a need for detailed, location-specific energy usage data to support accurate tracking, reporting, and potentially cost allocation across different departments or buildings within the university. This reflects a common need in institutional settings for granular data from aggregated utility invoices. ## Success The primary value demonstrated for the customer lies in the platform's core functionality for handling complex utility data. The discussion confirms that the system is fundamentally capable of the required task: breaking out a consolidated bill into individual sub-accounts based on meter numbers. The proposed solution involves creating distinct data blocks for each meter's usage, which aligns with established best practices for customers in similar situations. This capability is central to the product's value proposition for managing large, multi-meter accounts. ## Challenge The most significant challenge encountered by the customer has been a prolonged failure to achieve the correct implementation of the bill breakout feature. Despite the product's capability, there was a clear breakdown in execution. The customer received a consolidated bill where all usage was incorrectly attributed to a single building, rendering the data unusable for their location-based analysis. This issue persisted for an extended period, with customer requests reportedly going unaddressed, leading to frustration. The problem is compounded by its scale, as all historical bills dating back to the onboarding period (approximately September 2024) require manual rework to correct the usage allocation across meters and locations. Furthermore, the recent switch to a new energy supplier adds another layer of complexity to ensuring the solution is correctly applied moving forward. ## Goals The customer's objectives are clear and center on data accuracy and utility management efficiency: - To have electricity usage correctly broken out and attributed to its corresponding physical location (building) based on the individual meter number. - To have all historical billing data corrected retrospectively to reflect the proper usage per location. - To ensure that the billing structure correctly handles both distribution and supply charges within the new, corrected format. - To establish a clean, sustainable process for future bills, especially under their new energy supplier, to prevent a recurrence of the issue.

## Summary The meeting focused on critical operational challenges with manual invoice downloads and credential management, centering on the urgent need to fully leverage the Arcadia platform to automate these processes and ensure timely bill payments. ### Escalating Problems with Manual Invoice Processing The current manual system is failing, causing significant delays and financial risks. A specific incident was highlighted where a key client questioned why a utility bill issued on December 16th wasn't pulled until January 5th, missing its January 2nd due date. This delay exposes the company to potentially **astronomical late fees**, especially given the high dollar value of the accounts in question. The situation is deemed unsustainable, with the team acknowledging they are consistently behind despite extensive manual effort. ### The Strategic Decision to Fully Adopt Arcadia A consensus was reached to abandon the cautious, phased approach and fully integrate Arcadia for both credential management and automated invoice downloads. The reasoning is that the current state is so problematic that the risk of moving to Arcadia is lower than the risk of maintaining the status quo. The immediate plan is to transition all invoice downloading for a major client portfolio (Extension) to Arcadia as soon as possible, followed by another large portfolio (Wiktra). ### Complexities of Credential Management with Arcadia While pushing existing working credentials to Arcadia for download purposes is straightforward, setting up new or correcting faulty credentials through their management service is complex and time-sensitive. - **Required Data Hurdles:** Arcadia's credential setup requires detailed information (e.g., tax ID, corporate name, phone number) that the company does not typically collect, which could create the same blockers currently experienced internally. - **Lengthy Setup Timelines:** The credential management service itself can take up to **three months** to fully establish an account, underscoring the urgency to start the process immediately to avoid the same problems recurring months later. - **Validation and Handoff Process:** A clean, validated list of credentials and active accounts must be compiled and sent to Arcadia. This involves reconciling data between different internal systems to ensure accuracy before handoff. ### Technical Integration and Process Flow The discussion outlined the technical pathway for Arcadia-sourced data to enter the company's systems, prioritizing a low-risk initial approach. - **Initial PDF-Based Integration:** Initially, Arcadia will deliver PDFs, which will be fed into the existing Data Services (DS) pipeline exactly like a manually downloaded bill. This avoids creating a third, parallel system to manage. - **Future JSON Integration:** The ultimate goal is for Arcadia to send structured JSON data directly to the billing system (UBM), bypassing DS entirely, but this is a longer-term project due to mapping complexities. - **Preventing Duplicate Work:** Internal tools will be modified to automatically flag and remove tasks for accounts assigned to Arcadia, preventing team members from manually downloading bills that Arcadia is already tasked with retrieving. ### Mitigating the Risk of Duplicate Payments A major concern is that Arcadia might download bills that have already been processed, leading to duplicate payments. - **Existing Duplicate Checker:** The system has a duplicate checker that catches identical bills entering from different sources (e.g., mail vs. manual download), which should also catch Arcadia-sourced duplicates. - **Critical Exceptions:** This checker may **not catch notices or bills with late payment fees**, as these could be considered different documents. - **Testing Strategy:** One proposed method is to let Arcadia pull all bills and rely on the duplicate checker, then analyze the results. An alternative, more cautious approach is to first identify and exclude high-value accounts that have already been paid this cycle, starting the test with lower-value or unpaid bills to minimize financial risk. ### Immediate Action Plan and Next Steps The team agreed on a rapid execution plan to operationalize the decision. - **Priority Portfolio:** The Extension client portfolio (over 3,000 accounts) will be the first group transitioned to Arcadia. - **Credential List Finalization:** A validated and cleaned list of credentials and active accounts for Extension will be prepared for internal review, with a target to finalize and send it to Arcadia. - **Alignment with Arcadia:** A follow-up call with Arcadia is needed to clarify required fields for credential management and to understand their process for flagging and resolving data issues during setup. - **Internal System Readiness:** The engineering work to integrate Arcadia's PDF output into the existing DS pipeline must be prioritized to enable the transition.

## Summary The meeting primarily focused on resolving critical data synchronization discrepancies between the Data Services (DS) and UBM systems, outlining a cleanup strategy, and addressing an urgent technical issue with a vendor portal. A follow-up action on credential management was also discussed. ### Data Synchronization Discrepancies Between DS and UBM The core issue discussed was the mismatch in account records between the Data Services (DS) and UBM systems, with a specific focus on the Ascension account. The root cause appears to be that DS sometimes updates account numbers for existing billing IDs, whereas UBM retains the original account record from the initial setup bill, leading to duplicate or orphaned records in UBM. - **Identifying the Mismatch:** A significant number of Ascension accounts exist in UBM but are no longer present in DS, creating confusion and extra work. For example, the "Anderson" accounts showed a pattern where digits in the account number were flipped between the two systems. - **Root Cause Analysis:** The discrepancy occurs because UBM only creates accounts when receiving data from DS. If DS later updates an account number (instead of closing the old one and creating a new one), UBM is left with a stale record while DS moves on, breaking the link between the systems. - **Impact on Reporting:** This misalignment causes reports, like the late bill (LAD) list, to be inflated with accounts that may not require action, wasting operational time and creating reporting inaccuracies. ### Strategy for Account Cleanup and Investigation A multi-step approach was proposed to clean up the discrepancies, emphasizing caution to avoid creating new problems. - **Initial Focus on Ascension:** The team agreed to start with a deep dive into the Ascension account discrepancies as a pilot to understand the patterns before scaling the effort to other clients. - **Caution Against Premature Removal:** There was a strong recommendation against automatically removing unmatched accounts from the LAD report without full investigation, due to the risk of missing legitimate late bills and facing accountability questions. - **Proposed Investigation Paths:** Several methods to find the correct links between systems were brainstormed: - Comparing service addresses and commodities, which are more distinctive than location addresses, to match records. - Requesting a list of *closed* accounts from DS to see if simply closing the orphaned records in UBM resolves many cases, which would be a simpler solution than re-linking. - Checking if historical data exports or unique database IDs exist in DS that could provide a persistent link to UBM records even after account number changes. ### Updates to Reporting and Access Brief updates were provided on enhancements to business intelligence tools and user permissions. - **Enhanced Report Data:** The "raw account number" field has been added to the master counts report to aid in the cleanup and investigation work. - **User Access Management:** A request was made to grant a user named Jeffrey access to all BI reports on the consulting side, a task that requires specific administrative permissions. ### Credential Management System Overhaul An initiative to centralize and synchronize login credentials for vendor portals was discussed, aiming to eliminate future sync issues. - **Immediate Cleanup Required:** A spreadsheet comparing credentials between DS and UBM has been prepared and needs review by the operational team (led by Afton) to determine which records are accurate. - **Long-term Solution:** A new credential management interface is being built within the DSS application. This will serve as a single source of truth, providing instantaneous synchronization between all systems and replacing the current manual and error-prone processes. ### Urgent Issue: Constellation Energy Portal (CDP) Access An urgent, blocking issue was raised regarding the Constellation Energy Portal (CDP). - **Problem Identified:** The company's primary CDP profile has hit a system-imposed limit for the number of linked accounts, preventing any bills from being searched or downloaded, which halts operations for that vendor. - **Proposed Resolution:** The immediate workaround is to request that Constellation create a new portal profile under a different team member's name (e.g., Tara or Mary) to house additional accounts. This is considered a critical fix that needs to be implemented rapidly to avoid billing delays.

## الملخص نظرًا لقصر المقطع الصوتي المقدم والذي لم يتجاوز بضع ثوانٍ، لم يتم تناول أي مواضيع أو نقاشات فعلية خلال هذا "الاجتماع". المحتوى الوحيد كان تحية عابرة لا تشكل أساسًا لمحادثة أو اجتماع عمل يمكن تلخيصه.

## **Summary** The meeting focused on resolving critical data integrity issues across the billing and invoice processing systems, with a strong emphasis on establishing a single source of truth for account data. Discussions centered on immediate problems with lost invoices, long-term systemic improvements to validation logic, and the need for unified reporting. ### **Immediate Issues with Extension Accounts and System Gaps** A primary concern was a batch of extension accounts that appeared as "completed" in Data Services but never propagated to the UBM (Utility Bill Management) platform. The root cause is suspected to be a broken file stuck in an email queue. With a key development team unavailable, immediate resolution was pending, highlighting a fragile point in the data pipeline. Furthermore, it was noted that UBM currently has a significant backlog of approximately 2,400 items created from December to the present, indicating ongoing processing challenges. ### **Reconciling the Master Account List as the Source of Truth** A major point of alignment was the urgent need to reconcile account totals between Data Services and UBM, as current numbers do not match-sometimes by hundreds of accounts. UBM was agreed upon as the definitive source of truth for what accounts the company and its customers can see. The core problem is that discrepancies cause "missing" invoices to go unnoticed. A manual reconciliation exercise for one customer (Extension) is already underway to identify reasons for mismatches, such as formatting differences in account numbers or unlinked accounts. A broader, systematic cleanup involving pulling complete lists from both systems into a consolidated document (like Excel) for team review was proposed as a necessary next step. ### **Addressing Systemic Design Flaws in Data Processing** To move beyond one-off fixes for recurring validation and mapping errors, a fundamental redesign of the Data Services System (DSS) logic is in progress. The current system relies too heavily on generic AI/LLM rules, leading to frequent failures. The solution involves integrating customer-specific "build templates" directly into DSS. These templates will provide the precise rules (covering UAMs, locations, etc.) for the AI to follow per bill, which should address the majority of validation issues for web-downloaded invoices. Testing for this new logic is planned for the coming weeks. However, invoices from other sources (like BDE email uploads) that lack vendor/customer data will still fall into a manual review queue until a separate solution is developed. ### **Developing Unified Reporting and Dashboards** To improve operational visibility and eliminate manual reporting work, there is a push to develop a dynamic Power BI dashboard. This dashboard would automatically track key metrics like the number of unprocessed invoices per customer, using the same logic currently applied manually. A critical requirement is documenting the exact data sources and calculation logic ("a cheat sheet") to ensure everyone interprets the numbers consistently. A separate Power BI report for labs exists but is currently hampered by performance issues due to its size, requiring optimization before new features can be added. ### **Customer-Specific Account Cleanup Projects** Two specific customer account cleanup projects were reviewed: - **ERA Cleanup:** Work is ongoing and on track for a deadline of February 8th, with a subsequent cleanup for St. Elizabeth scheduled for February 23rd. - **Aurora University:** A significant, long-standing issue was revisited. Historical bills for this client were not processed correctly through DSS, resulting in inaccurate data in UBM. A manual cleanup of approximately 13 months of historical data is required, which involves both adding accounts in Data Services and correcting records in UBM. The client has requested an update by February 16th, and the operational teams will coordinate on the approach for both fixing the backlog and establishing a correct process for future invoices.

## **Project Status and Field Mapping Review** The meeting served as a project status update and working session focused on the integration of reporting systems. The primary objective was to clarify the mapping and purpose of specific data fields within critical financial reports to ensure a seamless transition and configuration for the new system. ### **Progress on Report Documentation and Field Identification** A list of reports and their associated data fields has been compiled into a shared spreadsheet for collaborative review. Significant effort is being invested to document each report's purpose, filters, and data structure, drawing from existing onboarding documents and system exports. - **Compilation of Source Materials:** The documentation integrates reports from multiple sources, including a shared repository from "Engie" and initial onboarding documents provided by Constellation. The goal is to create a single source of truth for all required reports. - **Detailed Analysis Approach:** For each report, the process involves opening the actual report to capture its filter selections and a data sample. This granular approach is intended to provide precise specifications for the development team, though it is recognized as a time-intensive task. - **Centralized Collaboration Tool:** All findings and questions are being centralized in a shared spreadsheet on the team's SharePoint site. A key housekeeping rule was established to **strike through** incorrect or inapplicable information rather than deleting it, preserving the audit trail of changes until consensus is reached. ### **Clarifying Critical Field Mappings for Financial Processing** A major focus was deciphering the exact meaning and destination of fields within a specific "consolidated" financial report. This report is used daily for operational tasks and is the file directly uploaded into the JD Edwards ledger system. - **Urgent Need for GL Mapping:** A critical priority was identified: providing a complete breakout of how each field in the consolidated report maps to the General Ledger (GL). Having this mapping is essential for the Constellation team to begin their development work without delays. - **Leveraging Operational Expertise:** It was confirmed that the financial report in question is used extensively for paying utility bills. The team member who uses this report daily possesses the operational knowledge to define each column's purpose, which is vital for accurate system replication. - **File Format Specifications:** Clarification was provided on the technical format of the delivered file. The operational file is a flat text file without column headers. The column names discussed in the meeting are logical labels applied by the business team for processing, which must now be formally mapped to the corresponding technical fields. ### **Adjusting Timelines Due to Operational Workload** The project timeline required immediate adjustment to accommodate the significant workload of the business team, who are concurrently managing period-end financial close activities. - **Deferring Detailed Review:** The business resources needed to provide field definitions are heavily occupied with closing responsibilities. Consequently, a scheduled working session was postponed to allow them necessary focus time. - **New Checkpoint Established:** A new checkpoint meeting was scheduled for the following week to assess progress on the field definitions. The expectation is that the preliminary work, especially the crucial GL mapping, will be completed by the end of that week. - **Recurring Coordination Meetings:** The teams agreed to reinstate a recurring weekly meeting series to provide overall project updates and track timeline adjustments, ensuring better ongoing coordination. ### **System Interface and Data Delivery Requirements** Alignment was reached on the technical requirements for the new system's output to ensure compatibility with existing downstream processes. - **Mandating Interface Consistency:** A firm requirement was established: the new system must generate an output file that is **identical in format and structure** to the file currently received. This is to ensure that existing JD Edwards programs that process and upload the data will not require any modification. - **Confirming Data Destination:** It was explicitly confirmed that the specific "consolidated report" being analyzed is the exact file that feeds into the general ledger. Therefore, all service start dates and other critical fields present on the current report must be included on the new interface file. ### **Administrative and Compliance Follow-ups** Brief updates were provided on ancillary administrative items necessary for the project's broader context. - **FBO Account Approval:** It was confirmed that the paperwork for the FBO (For Benefit Of) account has been approved by the compliance team, resolving that administrative item. - **Outstanding Fee Question:** A follow-up question regarding the ability to send a specific type of fee (BAI) to the new account was raised. The responsible party committed to checking with internal finance and reverting to the core project team.

## Summary The meeting focused on finalizing the reporting and accounting of work completed in December, with particular attention on two key deliverables: the system status report and the tracking of unplanned work. ### Completion Status of the December System Status Report This section clarifies the delivery status of a major December deliverable. While the report was technically finished, its official completion is being reconsidered due to ongoing feedback. - **Report delivered but pending revisions:** The primary "system status report" was submitted by the end of December. However, significant feedback was received both in late December and in January, which has not yet been incorporated. This outstanding work means the task is not considered fully closed. - **Interconnection with another report:** The system status report is closely linked with another deliverable, the "lab report," and feedback pertains to both. This interconnected complexity contributes to the decision to reclassify the completion date. - **Reclassification to January:** To accurately reflect the state of work, it was agreed to move the official completion milestone for this report from December to January. This avoids presenting the task as finished while acknowledging the substantial effort already invested. ### Allocation and Reporting of Unplanned Work The discussion centered on quantifying and documenting ad-hoc tasks and additional reports completed outside the original plan for December. - **Time allocation for unplanned tasks:** A preliminary agreement was reached to allocate 25% of the total December work time to "unplanned work." This percentage serves as a high-level metric for effort spent on unforeseen or reactive tasks. - **Documentation of additional reports:** Alongside the unplanned work, several additional reports were generated. An agreement was made to allocate 15% of the time specifically to these reports. A detailed list of these specific reports was to be provided separately to ensure precise tracking. - **Finalizing the December accounting:** The confirmation of these percentages (25% for unplanned work, 15% for additional reports) allowed for the finalization of the December work summary. The process concluded with an understanding that the specific list of reports would be submitted to complete the record.

## Summary The meeting focused on two primary objectives: finalizing a summary of the team's delivered value for executive review and conducting a detailed review and adjustment of the project plan for the first quarter of 2026. The discussion was centered on ensuring alignment on priorities and realistic timelines for upcoming technical and operational work. ### Project Timeline and Executive Reporting A key discussion point was the plan to formally extend the current engagement through the first quarter, pending executive approval. This extension is intended to solidify foundational improvements and transition to a more sustainable, long-term support model. - **Extension for Foundation Building:** The additional time in Q1 is seen as crucial for overcoming the initial implementation challenges and completing high-priority foundational work, which will reduce the need for intensive prioritization in subsequent phases. - **Preparation of a Value Summary:** There is a direct request for each team to provide a concise paragraph summarizing the business value delivered by their work. This summary, intended for executive leadership, should articulate how specific problems were solved and the resulting impact, serving as a record for performance reviews and organizational recognition. ### Review and Adjustment of the Q1 2026 Plan The majority of the meeting was dedicated to a month-by-month review of the planned work for January through March 2026, with adjustments made based on current progress and revised scope understanding. - **Data Validation and Rule Review:** A significant rules review effort is confirmed as a multi-month project, now expected to span January through March, with the bulk of the critical work targeted for completion in the first two months. - **Power BI Dashboard Development:** The priority for January is to establish reliable data pipelines from source systems into Power BI. The development of specific report views is dependent on this foundational data accuracy being achieved first. - **Credential Management and Account Health View:** A project related to UBM (User Behavior Monitoring) credential management and a holistic account health dashboard is a high-priority item, now slated for a January-February effort with hope for early completion. - **JIRA Integration and Customer Issues:** Work on integrating systems with JIRA for tracking customer issues remains scheduled for February, pending some final tweaks and deeper technical discussions. - **MFA (Multi-Factor Authentication) Initiatives:** Plans regarding MFA implementation from personal phones are tentatively kept in February but acknowledged as requiring further evaluation. - **Integrity Check and Template Layer:** The approach for building system integrity checks has evolved. The focus is now on creating a standardized account template, which will reduce the immediate priority and scope of a separate "Interpret layer," pushing that item later into the quarter. - **Phase Two of Emergency Payments:** A subsequent phase involving bank pulls for emergency payments is noted for March, contingent on continued coordination with external partners. ### Overall Progress and Forward Look The session concluded on a positive note regarding the team's overall trajectory and collaboration. - **Acknowledgement of Team Effort:** The significant progress and consistent engagement from the team in weekly prioritization sessions was explicitly recognized as having placed the project in a strong position. - **Anticipated Future Reporting:** Teams were advised to maintain their own records of delivered value, as a similar summary exercise will likely be required at the end of the first quarter to demonstrate the value of the extended engagement period to stakeholders.

## Summary ### Task Management and Jira Setup The meeting began with a discussion on establishing a structured task management system for upcoming projects, particularly focusing on the use of Jira's timeline and board views. The primary goal was to create a centralized, running list of all required tasks to ensure clarity and alignment, especially for early-phase spike research tickets. - **Utilizing Jira for project tracking:** It was emphasized that using Jira's timeline view, either within the main board or opened in a new page, would be the method for logging all tasks related to the Arcadia effort and other workstreams. This approach aims to provide full visibility into the work that needs to be done. - **Capturing early research work:** A specific need was identified to document spike and research tickets from the outset of the Arcadia project, ensuring these foundational investigative tasks are properly tracked and accounted for in the overall project plan. ### Arcadia Integration and Updates A significant portion of the discussion revolved around the ongoing integration with Arcadia, covering both code deployment and potential dependencies on the DSS (Data Submission Service). - **Code deployment strategy for edits:** There was a deliberation on when to push completed edit functionality to production. The consensus was to proceed with the deployment since the feature is not yet in active use; however, the ideal process would involve gathering operator feedback and implementing activity history tracking before a full rollout. - **Identifying dependencies on DSS:** A key point was raised regarding the Arcadia integration's reliance on the DSS. If any part of the Arcadia work requires updates from the DSS side, that responsibility will fall to the current team, highlighting a potential area of inter-system dependency that needs monitoring. ### Credential Management for Vendors A detailed update was provided on the progress of managing vendor credentials, which are critical for system integrations, including the upcoming work with Arcadia. - **Current state analysis in FDG and UBM:** - **FDG Project:** Credentials are currently stored in an encrypted form within a Windows credential table in the DDS database. UI development in the DSS app to display these credentials is complete, and work is now focused on building the APIs to fetch this data. - **UBM Application:** An investigation into the UBM (Unified Build Management) system could not locate a dedicated credentials management page or database table. The team is uncertain where UBM credentials are stored, noting a previously shared Excel sheet with thousands of vendor credential entries that may or may not be the source. - **Unifying credential storage:** The long-term objective is to establish a single source of truth for credentials that serves both the DSS and UBM systems, moving away from fragmented and manual storage methods. ### Syncing Challenges and a New Development Approach The conversation highlighted significant challenges with the current, semi-manual process of syncing credentials between different systems and outlined a new development path forward. - **Problems with the current manual sync:** The existing sync process, managed by an individual team member, is prone to periods of being out-of-sync. Major issues include an inability to definitively identify the source of an update (DSS, UBM, or Smartsheet) and, consequently, no clear source of truth. Updates made directly in Smartsheet are especially problematic as they exist completely outside of any integrated system. - **Immediate development priorities:** Given the uncertainty around the sync mechanism, the immediate plan is to develop core credential management functionalities-**add, edit, delete**-within the new system. This will include fields for created/updated dates and a notes section. A formal Jira ticket will be created to capture these requirements. - **Need for architectural clarity:** A fundamental question remains unresolved: whether UBM will point to the new credential database or if another syncing architecture will be required. Collaboration with the team member who currently handles the sync is needed to understand the existing workflow before a new solution can be designed. ### Future Considerations for Arcadia The critical importance of robust credential management was underscored in the context of future work with the Arcadia platform. - **Credential passing for builds:** It was clarified that vendor credentials will need to be passed to Arcadia with every request to retrieve new builds. This dependency makes solving the credential storage and syncing problem a high-priority prerequisite for successful Arcadia integration, elevating its importance on the project roadmap.

## Summary The meeting focused on critical operational issues related to duplicate bill processing within the system, identifying several interconnected problems and their root causes. The discussion centered on inefficiencies in the duplicate resolution workflow, data integrity issues with bills from automated sources, and systemic bugs that obscure the true status of documents. ### Duplicate Resolution Workflow Challenges A significant challenge is the inability to efficiently verify potential duplicate bills, leading to extensive manual work. When bills are flagged as duplicates, the corresponding PDF often fails to display on the duplicate resolution screen for comparison. This occurs because the system does not store the invoice's header information-such as date, due date, and total charges-on the bill record when it is initially marked as a duplicate. Consequently, team members must manually investigate each flagged bill behind the scenes, a process that has become unsustainable given the volume of duplicates. This issue is compounded by the recent practice of processing change of addresses for all accounts, including those enrolled in web downloads, which has significantly increased duplicate submissions. ### Root Causes of Duplicate Influx The surge in duplicate bills stems from multiple entry points and systemic gaps. One primary source is the **Big Data Energy (BDE)** integration: their automated bot scrapes customer portals per account based on an expected invoice date but does not reference the last bill pulled. This can result in the bot fetching the previous month's bill repeatedly if a new one hasn't posted, causing both duplicates and late bill submissions. Furthermore, bills submitted via BDE or other web downloads often enter the system with "unknown" client and vendor fields, routing them through DSS and contributing to the backlog before they are properly identified. ### Critical System Bugs and Data Integrity Two major technical bugs were identified as exacerbating the problem. First, in the **DSS system**, when a bill is marked as a duplicate based on a file checksum, the system fails to store that checksum on the bill record. This prevents the duplicate PDF from appearing in the resolution queue, leaving reviewers blind. Second, a severe **data integrity issue** was uncovered: bills can be uploaded under incorrect account numbers but still be flagged as duplicates. Since the duplicate resolution screen does not display the account number to which a bill is attached, reviewers cannot easily identify this error. In some alarming cases, bills have appeared in the workflow completely detached from any client, vendor, or account-a scenario that should cause a system crash but currently does not. ### Proposed Solutions and System Improvements Several targeted fixes and enhancements were agreed upon to address these core issues. The immediate technical fix is to correct the bug in DSS so that the checksum **is properly stored** when a duplicate is detected, ensuring the PDF appears for comparison. A second crucial enhancement is to **modify the duplicate resolution user interface** to display the account number (and client/vendor information) attached to each bill. This will allow reviewers to instantly spot mismatches, such as a duplicate bill uploaded to the wrong account. Additionally, there was a proposal to add **system-generated activity logs** for DSS processes within the bill record to improve auditability and tracking. ### Process and Policy Considerations Beyond technical fixes, broader process issues were discussed. The practice of allowing both mailed paper bills and web downloads for the same accounts following a change of address is a major contributor to the duplicate volume. While disallowing dual sources was suggested as a way to minimize duplicates, it was acknowledged that customer demand for fast, digital processing makes this a complex policy decision. The team emphasized that until systemic fixes are implemented, the duplicate resolution queue will remain a significant bottleneck requiring constant manual oversight to prevent processing errors and ensure data accuracy.

## Summary The meeting centered on planning the strategic priorities and technical foundations for Q1 of 2026 and beyond, with a strong focus on resolving systemic pain points and establishing robust, scalable processes. The discussion outlined a series of interconnected initiatives designed to overhaul outdated systems, improve data integrity, and create shared services for the broader Navigator platform. ### Onboarding Process Overhaul **A complete redesign of the customer onboarding workflow is necessary to eliminate reliance on informal, error-prone methods.** The current process, which often depends on emails, spreadsheets, and unrecorded calls, leads to scope creep and inconsistencies. - **Structured Onboarding UI:** The post-contract onboarding experience must be moved into a formalized UI. This system should capture and require verification of all critical contract details like meter counts, account numbers, vendor lists, and pricing plans directly from the customer to serve as a single source of truth. - **Centralized Setup Documentation:** A documented and trackable process for bill setup needs to be created. This involves generating a unique document ID from the onboarding process for each account/vendor combination, where all associated bills can be linked and tracked, eliminating disputes over what was or wasn't received. - **Integration with Build Template Creation:** The onboarding system should seamlessly connect with the creation of build templates. The ideal flow would allow for the automated generation or easy manual creation of a build template based on the verified setup information provided during onboarding. ### Bill Data Processing and System Integration **Improving the flow and accuracy of bill data processing is critical, with particular attention paid to the role of build templates and the integration of new data services.** - **IPS and Build Template Integration:** A major gap was identified where the LLM-based Intelligent Processing Service (IPS) does not currently use the existing customer-specific build templates to enrich bill data. This leads to generic, often incorrect inferences and has resulted in tens of thousands of inaccurate line items that will require a cleanup process. - **Enabling Shared Navigator Services:** The IPS and DSS (Data Storage Service) capabilities need to be packaged as a shared "drag-and-drop" service. This will allow other Navigator applications like Carbon Accounting and Glimpse to send PDFs and receive enriched JSON, enabling them to build their own services without waiting for a full UBM (Utility Bill Management) integration. - **Third-Party Service Management & Logging:** As reliance on third-party data providers (like Arcadia) increases, a new, dedicated logging and mapping layer is essential. This system must track every interaction-monitoring SLAs, logging API call failures, and mapping provider outputs to internal formats-to quickly identify where breakdowns occur in the data supply chain. ### Credentials and Data Source Management **Managing customer credentials for third-party data access requires a systematic, auditable approach rather than the current fragmented method.** - A centralized, filterable system is needed to view all credentials (e.g., for utility portal access) for a given client, vendor, and account. This allows for ongoing verification by clients and ensures any credential changes are updated in one place and propagated correctly, preventing data flow interruptions for high-value contracts. ### Strategic System Transition and Legacy Sunsetting **The long-term strategy involves methodically migrating functionality from the legacy DDS system to the modern DSS platform while clearly defining what remains.** - **DDS Functionality Assessment:** The immediate goal is to catalog what critical functions still reside solely in DDS. The primary items identified were bill setup workflows, summary bill processing, and the underlying customer-vendor-account data (build templates). The intent is to replicate or improve these in DSS. - **Defining the Sunset Path:** The transition is not about a hard cutover but about making DSS so comprehensive and reliable that reliance on DDS naturally diminishes. The focus is on building the new capabilities in DSS first, ensuring they work for operators, and then deprecating DDS components as they become redundant. ### API Development and Future-State Vision **The end-state vision involves exposing clean, normalized data through APIs to both internal applications and external channel partners.** - **Navigator Shared APIs:** The plan is to develop a set of callable APIs that provide access to normalized bill data (in both DSS and application-specific formats like UBM JSON). This would allow technical customers or partners to directly query for their data, serving use cases like integration with platforms such as Azure. - **Empowering Internal Teams:** Application teams like Carbon Accounting will be empowered with the enriched DSS JSON and documentation so they can build their own normalization layers and APIs independently, accelerating development across the Navigator suite. ### Foundational Issues and Success Metrics **The conversation concluded by identifying the root causes of ongoing operational issues and the criteria for success in 2026.** - **Core Pain Points:** The recurring "fires" are traced back to four interconnected gaps: not using build templates in IPS, shortcomings in data acquisition from third parties, inadequate logging/reporting, and drift in master data sources. Solving these is seen as the key to freeing up bandwidth from constant firefighting. - **Expectations for Q1 2026:** There is a strong expectation that by the end of Q1 2026, significant progress must be visible on these core pain points. The goal is to resolve the majority of the daily operational issues reported by Data Services and UBM teams, moving from identifying problems to executing the built solutions.

## **Analysis and Improvement of DSS Invoice Matching Logic** The meeting centered on a deep technical dive into the Data Services System (DSS) invoice matching logic, with the primary objective of diagnosing persistent issues causing incorrect line item and meter creation. The discussion deconstructed the current multi-phase workflow to identify root causes in vendor matching, data normalization, and the overall integration with the AI (LLM) extraction process, concluding that a fundamental paradigm shift is required to improve accuracy. ### **Overall Problem Statement and Initial Focus** The core issue is that the system frequently fails to correctly match incoming invoice data with existing database templates, leading to the erroneous creation of new meters and line items instead of mapping to known ones. This results in data duplication and workflow inefficiencies. The immediate diagnostic focus was placed on three key areas: improving the core matching logic with potential "fuzzy" matching, cleaning up legacy data, and defining a clear process for handling invoices without an exact template match. ### **Deconstructing the Existing Matching Workflow (Phase 1)** The team meticulously walked through the documented matching flowchart to understand each failure point. - **Step 1: Vendor ID and Account Number Matching:** This initial gate relies on a vendor ID and account number. The analysis revealed critical vulnerabilities: these identifiers can be captured at upload or inferred post-IPS extraction, leading to potential mismatches. A major concern is the translation of a vendor *name* (from IPS) to a vendor *ID* (a number used for database lookup), which may fail if not an exact match. Furthermore, account numbers could be captured differently (e.g., with dashes or leading zeros), requiring normalization to ensure reliable string matching. If this step fails, the process cannot proceed to use an existing template. - **Step 2 & 3: Service Account and Meter Fetching:** Upon successful vendor/account matching, the system fetches all related service accounts (e.g., "Full Service," "Distribution Only") and their associated meters. The logic assumes that for existing customers, these entries should always be present. The discussion confirmed that the system pulls *all* service accounts and meters for the matched account, without initial filtering, which is a potential point for future optimization. - **Step 4: Line Item Fetching and Failure Paths:** Line items are fetched specific to each meter. The meeting clarified the hierarchical dependency: if vendor/account matching fails, meter matching inherently fails, leading to the creation of new structures from IPS data. This results in a bill being created without a linked customer account (`client_id` set to `null`), sending it to a manual review queue. ### **Identifying Specific Matching Failures** The conversation pinpointed exact scenarios where the current logic breaks down, using a real invoice example. - **Meter-Level Matching Criteria:** Meters are matched using a combination of **commodity description**, **rate code description**, and **service address**. The example showed that while the commodity matched, the rate code failed because the IPS extraction captured "Commercial Service" while the database record contained the full string "Rate 4: Commercial Service." This exact string mismatch caused a new meter to be created. - **Issues with Extracted Data:** The **rate code** and **service address** are particularly prone to extraction variance by the LLM. The address, especially, requires "fuzzy" logic for matching, as minor differences in formatting can cause failures. The **commodity description**, while more stable, can also be misidentified. ### **Core Flaw: Disconnection Between Template and AI** A critical insight emerged regarding the fundamental design of the comparison phase (Phase 2). - **Phase 2 (Comparison) Limitations:** The system compares the IPS-extracted "enhanced JSON" with the database template. However, it was determined that the process only *overwrites* the IPS data with database values **when an exact match is already found**. The database template does not actively *guide* or *constrain* the initial LLM extraction. - **Circular Logic Problem:** Essentially, the system uses the database to clean up data only after the AI has already made its best guess. If the AI's extraction is poor (e.g., on rate code), no match occurs, and the incorrect AI data is kept, leading to new entries. The existing template is not being utilized as a prior input to make the AI's extraction more accurate in the first place. ### **Proposed Solutions and Strategic Rethinking** The conclusion was that incremental tweaks are insufficient; a new approach is needed to tightly couple the known template data with the AI processing stage. - **Feed Templates to the LLM:** The proposed solution is to dynamically feed the known invoice template for a matched vendor/account **into the LLM system prompt** *before* extraction. This would instruct the AI to use the existing line item descriptions, commodity types, and rate codes as a reference, forcing it to align its output with the known structure. - **Implement Confidence Scoring:** The enhanced system should include confidence scores from the LLM. For example, extractions with less than 90% confidence could be flagged for review, and those below a lower threshold could require mandatory manual intervention, preventing incorrect automated creation. - **Ownership and Research:** The team resolved to take full ownership of this logic. Immediate next steps involve a thorough review of the existing LLM system and user prompts, the template matching code, and the exact method by which vendor names are translated to IDs. ### **Action Plan and Administrative Notes** The session concluded with a clear action plan and ancillary discussions about tooling access. - **Immediate Technical Investigations:** The team will review three key areas: the LLM system/user prompts governing extraction, the logic for translating vendor names to IDs, and the overall design of the template matching and comparison workflow. A meeting with the original developer was also scheduled to gain historical context. - **Development and Testing Path:** Changes to the LLM prompts can be made by cloning the repository, creating a feature branch, and deploying to a development environment for testing. This allows for controlled experimentation with new prompting strategies. - **Access and Infrastructure Issues:** A significant blocking issue is the inability to access internal tools (like FTG Connect) due to VPN/client conflicts on non-company hardware. This hinders the ability to test changes and investigate issues directly, and resolving this access problem was noted as a high priority for enabling effective development.

## Summary The meeting focused on a critical issue in the automated bill processing system where the Large Language Model (LLM) is creating duplicate line items instead of correctly matching them to existing templates. The core problem stems from a mismatch in the *commodity item description* and minor formatting differences, causing the system's exact-match logic to fail. The discussion centered on diagnosing this issue, understanding how the LLM makes classification decisions, and exploring strategic solutions to improve matching accuracy. ### Issue with Exact-Matching Logic The current system's exact-match requirement for three fields-caption, unit description, and commodity item description-is too rigid, leading to unnecessary duplication. Minor discrepancies, such as whitespace or slight wording variations, cause the system to create new line items instead of matching existing ones. - **Failed Matches Due to Minor Variations:** The primary example discussed was an "Ascension" account where the LLM classified a line item as "use build UCPR," but the manually entered template had it as "adjustment UCPR." This difference caused a complete match failure, leading to the creation of a new, redundant line item. - **Sensitivity to Formatting:** Another example highlighted how a simple whitespace difference in a caption (e.g., "Natural Gas Cost - DTHMS" vs. "Natural Gas Cost- DTHMS") was enough to prevent a match, even though the commodity item description ("commodity adjustment") was identical. - **Impact on Data Integrity:** This behavior risks creating a cluttered and inaccurate dataset with multiple line items for the same charge, which could skew consumption and cost analysis. The focus was on ensuring the *commodity item description* is correct above all else, as this directly impacts financial and usage reporting. ### Analysis of LLM Classification & Prompt Structure To address the root cause, the conversation delved into how the LLM is instructed to classify line items from invoice OCR data. The system uses a combination of a *system prompt* and a *user prompt* to guide its decisions. - **Dual-Prompt Architecture:** The *system prompt* defines the AI's persona and core identity (e.g., an "energy specialist"), while the *user prompt* provides specific, task-oriented instructions and the actual OCR data to process. - **Current Instruction Set:** The prompts contain general rules and some vendor-specific instructions (e.g., for Constellation). However, the analysis revealed that the instructions might not be sufficiently detailed or contextual to handle the nuances of every vendor's billing terminology, leading to misclassifications like "use build" vs. "adjustment." - **Inference Process:** The LLM chooses a commodity item description from a provided list of mappings. The challenge is that without precise, context-aware guidance, it can select a semantically close but technically incorrect term, which then breaks the downstream matching logic. ### Proposals for Enhancing Matching Accuracy Several solutions were proposed to make the system more robust and accurate, moving beyond brittle exact-matching. - **Implementing Fuzzy Logic:** A primary suggestion was to introduce fuzzy matching, at least for fields like captions. Pre-processing text by removing extraneous whitespace or special characters before comparison would prevent matches from failing on trivial formatting differences. - **Revising and Expanding LLM Prompts:** The need to meticulously review and enhance the prompt instructions was emphasized. This could involve: - **Adding Vendor or Commodity-Specific Rules:** Creating a database of granular instructions keyed by vendor ID or commodity type. This would allow the system to apply highly relevant rules (e.g., "for Vendor X, term 'UCPR' should always be classified as 'adjustment'") during processing. - **Structuring Prompts for Performance:** Concern was raised that a single, ever-growing prompt file might become less performant. The idea of breaking instructions into modular, conditionally applied blocks based on the bill's context (vendor, commodity) was discussed as a potential optimization. - **Leveraging Existing Account Templates:** A more fundamental solution was proposed: instead of (or in addition to) complex prompt engineering, the system could fetch the known correct template for an account and instruct the LLM to use it as a primary reference. This would dramatically reduce guesswork and ensure consistency with historically approved line items. ### Strategic Direction and Next Steps The discussion concluded with a strategic pivot towards a more template-driven approach and a plan for focused testing. - **Prioritizing Template-Based Matching:** The consensus shifted towards viewing the pre-existing account template as the single source of truth. The immediate action is to explore modifying the system to pass the known template to the LLM, guiding its classification to align with established data rather than relying solely on its interpretation. - **Targeted Investigation and Cleanup:** Before a full-scale change, a deep dive into specific failure cases (like the Ascension bill) was planned. The goal is to understand exactly why the LLM chose an incorrect description and whether the correct option was even available in its mapping list. - **Phased Implementation and Review:** The approach will be iterative. Changes would ideally be tested on a select customer account first to observe the impact in a controlled environment before broader deployment. This allows for careful review of the LLM's output against expected results.

## Summary ### Power BI Deployment and Configuration Issues A significant technical challenge is preventing a newly created Power BI capacity from functioning correctly. The reports are inadvertently running on a shared, deprecated capacity instead of the dedicated deployment set up last week. This is causing refresh failures and performance limitations, with the system currently constrained to a 1GB memory limit. - **Incorrect Capacity Assignment:** Despite the new workspace being correctly assigned to the dedicated capacity, data refreshes are being executed on a legacy shared cluster. This misconfiguration is the core issue preventing the team from utilizing their new resources. - **Memory and Performance Constraints:** The system's current 1GB limit is insufficient for the reports, but upgrading to a higher tier (like F32) is considered cost-prohibitive. The team is actively seeking a more efficient solution. - **Lack of Internal Expertise:** A knowledge gap exists regarding the detailed configuration of Power BI's backend settings. The team finds the tool complex and requires deeper understanding to troubleshoot the capacity routing problem effectively. - **Contingency Plans:** The immediate plan is to conduct a more in-depth investigation. If the issue cannot be resolved internally, the team will examine the setup used by another business unit (UBM) and await the return of an internal expert, Sergio, for guidance. ### Team Availability and Schedule Coordination The discussion included aligning on upcoming holidays and individual availability to ensure project continuity. Key dates were identified that impact the ability to resolve the Power BI issue and plan future work. - **Upcoming Holiday Closure:** The team confirmed a holiday period spanning two specific dates in early January, during which key members will be out of office. - **Clarification of Working Days:** It was noted that the day immediately preceding the holiday is technically a working day, though some team members may be on leave. This clarification was important for planning follow-up discussions and work. ### Meeting Cadence and Ownership Transition A substantial portion of the meeting focused on re-evaluating the purpose and leadership of the recurring team call. The current structure, inherited from a past project phase, was deemed no longer optimal for the team's size and workflow. - **Evolution from Formal Agile to Ad-Hoc:** The call has already shifted from a traditional daily stand-up format to a more informal, as-needed discussion forum. This change reflects the team's smaller size and the practical need to discuss only pertinent blockers or topics. - **Proposal for Full Ownership Transfer:** A clear proposal was made for the product owner to take full ownership of the meeting. This includes the authority to change its schedule, frequency, and participant list to better suit the team's current operational needs. - **Current Facilitator's Supportive Stance:** The individual currently running the meeting expressed full support for the transition. They acknowledged their limited availability and explained that their involvement was originally a "free service" from another department that is no longer being fully utilized. They offered to remain available as an optional resource for coaching or historical context. - **Financial and Structural Considerations:** It was clarified that the scrum master services were previously charged internally, but the team has not been leveraging this structure. The discussion opened the possibility of formally discontinuing this service or seeking alternative Agile coaching support if desired in the future. ### Strategic Planning for the Upcoming Year The conversation naturally extended into preliminary thoughts about the team's operational strategy for the next year, linking the meeting structure to broader goals. - **Desire for Increased Meeting Frequency:** There is an interest in making team syncs more frequent, contingent on the availability of team members and the new meeting owner's capacity. - **Alignment with 2026 Objectives:** The restructuring of the meeting is seen as a step toward better aligning the team's daily communication with its strategic goals for the coming year. The need to understand broader organizational plans for the team in 2026 was also highlighted as important for future planning. ### Next Steps and Follow-up Actions The meeting concluded with a clear plan for immediate follow-up and a checkpoint to finalize decisions. - **Immediate Technical Investigation:** The primary action is to continue troubleshooting the Power BI capacity issue independently before escalating or waiting for external help. - **Scheduled Decision Point:** A follow-up discussion is planned for the following week to finalize the transition of meeting ownership and to define the new schedule and format. This allows time for the product owner to consider the optimal structure.

## **Progress on Data Reparsing and Validation** The meeting opened with a discussion on the technical status of data processing systems. Validation procedures for data parsing have been successfully restored and are fully operational. A key action point was to proceed with re-parsing historical billing data for the Royal Farms client, specifically covering all records from May to the present. This task was estimated to take approximately one hour to execute. ## **Client Data Cleanup Timelines and Responsibilities** A significant portion of the discussion centered on upcoming data cleanup projects for specific clients. The immediate focus is on preparing data for a client meeting scheduled for the 5th, with a firm deadline for clean data set for the 8th. The cleanup process was slated to begin imminently, with the goal of completion by the following Monday, the 7th, accounting for team availability and coverage. The responsibility for managing this cleanup process and serving as the primary point of contact for related communications was clearly assigned. Developer representation in client meetings was discussed as a temporary measure to address ongoing platform issues until the systems are stabilized. ## **Upcoming Projects and System Adjustments** The conversation shifted to future work, highlighting an upcoming, more complex data project for a university client. This project is anticipated to involve splitting a single account bill across a large number of individual meters (e.g., 12-20), presenting a unique technical challenge. While the scope is not fully defined, it was noted that managing one complex account is preferable to handling hundreds of simpler ones. This foreshadows a need for system adjustments and development work to handle such billing structures effectively. ## **Cross-Team Communication and Issue Resolution** An operational challenge was raised regarding communication delays with an external payment processing team ("Pay"). Internal teams have reported not receiving responses for weeks on specific payment inquiries, such as issues with uncleared checks or discrepancies in remittance addresses. While one channel for payment questions has been responsive, this particular backlog indicates a breakdown that requires escalation and follow-up to resolve the outstanding issues for the operations team. ## **Strategic Alignment on Meeting Participation** A strategic discussion occurred concerning the allocation of meeting responsibilities. There was a consensus to limit developer attendance in routine client cleanup meetings in the long term. The preferred model establishes a primary point of contact for cleanup communications, while a separate individual handles broader client relations. Developer participation is seen as a temporary necessity to troubleshoot persistent platform issues but is not sustainable for ongoing operational meetings. The intent is to return to the standard communication protocol once system reliability is confirmed.

## **Summary** ### **Problem Analysis: Bills Stuck Due to Template Mismatches** The core issue discussed was the failure in the document processing (DSS IPS) workflow when a bill cannot be properly matched to an existing account or template. When a match fails, the system incorrectly proceeds to create new line items, meters, or other data, which cascades into significant downstream problems. This creates non-conforming data and leads to "stuck" bills that require manual intervention to resolve. - **Root Cause: Inadequate Matching Logic**: The primary failure point is at the initial matching stage. If the system cannot match a PDF bill to an existing account number or find the correct bill template, it should not proceed with any automated creation. The current logic allows it to move forward, generating inaccurate data. - **Cascading Data Issues**: Creating new line items based on unmatched data results in entries that do not conform to what the broader system expects, causing validation failures and operational headaches. This problem extends beyond just account matching to include line-item-level mismatches on criteria like caption, commodity, and item description. ### **Proposed Solution: A Fail-Safe Workflow** The agreed-upon solution is to redesign the workflow to halt automatic processing upon any matching failure and instead flag the bill for human review within the DSS system. This prevents the creation of bad data and surfaces the specific error. - **Implement Hard Stops**: The system must be configured to stop entirely and not create any new database entries if a match for an account or template is not found. This is the critical first step to prevent data corruption. - **Introduce Descriptive Error Statuses**: Instead of a generic "in progress" status, bills that fail matching should be assigned a clear, descriptive status such as "Template Mismatch" or "Template Validation Failed." This immediately informs an operator of the nature of the problem. - **Surface Detailed Error Information**: For each failed bill, the system should display a detailed error message. This note would specify the exact cause of the failure-for example, which account field did not match or which line-item commodity was not found-providing the context needed for an operator to fix it. ### **Enabling Manual Resolution and Template Management** For bills that fail automated matching, operators need tools within the DSS interface to manually resolve the issue and instruct the system on how to process similar bills in the future. - **Manual Template Selection Interface**: A new screen or pop-up within the DSS application should allow operators to manually select the correct bill template for an unmatched account. This gives a human the ability to make the correct association that the automated logic missed. - **Training the System for Future Matches**: The solution must include a mechanism for the system to "learn" from these manual interventions. When an operator selects a template for a specific account or set of bill characteristics, DSS should remember that association and use it for automated matching in the future, gradually improving its accuracy. ### **Strategic Next Steps and Cleanup** Addressing this problem is recognized as a multi-phase initiative that requires both immediate fixes and longer-term cleanup of existing data. - **Phase 1: Investigate and Improve Matching Logic**: The first action is a focused investigation ("spike") to analyze exactly where and why the current matching logic fails. The goal is to refine the algorithms to maximize successful automatic matches before any other changes are made. - **Phase 2: Data Cleanup**: Existing line items and other data that were incorrectly created by the DSS system in the past must be identified and deleted. This cleans up the database to remove noise and inaccuracies that could hinder future processing. - **Phase 3: Leverage Existing Templates**: A principle was established to always utilize existing line items from validated bill templates wherever possible, rather than creating new ones. Special attention was noted for line items with "use cost" or similar descriptors, which have been a particular source of errors. ### **Review of Other Development Items** The latter part of the meeting included a brief review of the current development pipeline in a testing environment. Several items were confirmed as completed and ready for, or already deployed to, production. - **Confirmed Production Deployments**: Items such as the lab report feature, a prompt update for a specific vendor (Constellation), and a fix for automatic page refresh were verified as working in production. - **Team Deployment Authority**: It was confirmed that the development team has the necessary privileges to push validated changes from the preview/staging environment directly to production, streamlining the deployment process. - **Ongoing Monitoring**: The team committed to reviewing remaining tickets, particularly those related to the bill template project, to ensure they are moved forward appropriately, with an understanding that current usage patterns allow for safe deployment.

## Q1 Foundation and Priorities for DSS The meeting focused on establishing the groundwork for key Data Services (DSS) initiatives planned for the first quarter. The primary objective is to move beyond daily firefighting and set a sustainable foundation for new integrations and system improvements. Two main technical efforts were prioritized for immediate action: integrating Constellation bill data and adding new third-party data sources, starting with Arcadia. A parallel, crucial initiative involves unifying and managing customer credentials across different platforms to ensure data integrity for these new integrations. ## Constellation Bills Integration Strategy Integrating Constellation bills into DSS requires careful navigation of internal access and methodology decisions. The core challenge is determining the best method to retrieve Constellation bill data. There are two internal approaches under consideration: one filters customers based on deal factors, while another aims to access *all* Constellation bills. The deal-factor method is seen as limiting because it could miss certain customer segments, like those with embedded UBM. Therefore, the preference is leaning toward the second, more inclusive option to avoid future gaps and re-work. **Access and coordination are significant hurdles.** The Constellation network has strict access controls, preventing standard external connections. This necessitates close collaboration with the internal team managing the data pipeline (referred to as "Laser Fisher") to understand how to retrieve the data within their network. The plan is to join ongoing discussions with that team to clearly define requirements for DSS, separate from any other projects (like carbon accounting) that may have caused prior confusion. ## Onboarding Third-Party Data: Arcadia and UtilityAPI The integration of new data sources, particularly Arcadia, is a major pillar of the Q1 plan, with UtilityAPI as a secondary, cost-effective option for specific vendors. **Arcadia is the preferred starting point** due to its robust documentation, high vendor coverage, and reliable webhook notifications for new bill availability. The foundation work involves setting up new services in DSS to listen to these webhooks, fetch bills and their accompanying JSON data, and map this information into the DSS structure. A Python script for normalizing Arcadia's JSON into the DSS format already exists and will be shared as a starting point. **UtilityAPI has limitations,** such as issues with multi-factor authentication (MFA) for some utilities and a less event-driven model (relying on polling). It would be used selectively for high-volume, cost-sensitive scenarios where its coverage is sufficient. The architecture for these integrations must be modular, allowing the underlying data provider to be swapped with minimal disruption to the core workflow. ## Unifying Credential Management A critical dependency for all new integrations is establishing a single, reliable source of customer login credentials for utility websites. Currently, credentials are stored separately in DSS, UBM, and even in decentralized Smartsheets, leading to discrepancies. An analysis revealed mismatches in usernames, passwords, and account numbers between systems for the same customers, which would cause failures in automated bill retrieval. **The proposed solution is to create a new, unified credential database.** This database would become the single source of truth, and all other systems (DSS and UBM) would either write to it directly or have their updates synchronized to it. **Immediate action involves manually reconciling a small batch of discrepancies** (estimated at around 20 records) to clean the initial data set. Long-term, the goal is to deprecate the use of Smartsheets for credential storage entirely and ensure any UI or process that updates credentials feeds into this centralized store to prevent future drift. ## Data Normalization and Process Architecture The approach to handling incoming data from new sources involves creating a flexible, maintainable pipeline for transformation and storage. The process must handle two parallel flows: one where a PDF is fetched and processed through DSS's existing engines, and another where the provider's native JSON is transformed directly into the DSS format using a custom normalization service. Initially, both paths may run to validate accuracy, but the long-term vision is to rely on the normalized JSON to reduce DSS processing load. **Maintaining data lineage is essential.** The plan includes storing the original provider JSON alongside the transformed DSS JSON and the final PDF. This ensures full traceability for debugging and audit purposes. Each data source (e.g., Arcadia, UtilityAPI) will require its own maintained normalization mapping code, which is anticipated to need periodic updates and troubleshooting, especially during the initial onboarding phase. ## Testing, Quality Assurance, and Rollout A phased, careful rollout is planned to avoid creating a new stream of operational issues. Before onboarding live customer data, the team plans to conduct thorough testing using existing credentials and historical bill data. This "dry run" will help identify data quality issues, assess the speed of data flow from source to DSS, and compare the output from the new normalization service against the established DSS PDF processing results. The goal is to proactively **identify vendor-specific "kinks" or coverage gaps** offered by the third-party providers. The strategy emphasizes minimizing "fire drills" post-launch by investing in upfront testing and ensuring a robust credential management system is in place first, as credential errors are a primary source of failure. ## Long-Term Vision for DSS Operations The overarching aim is to evolve DSS into a more streamlined and predictable system. The desired end-state is a clean, accountable process: for any given client, the system has a verified set of credentials, uses them to fetch bills via APIs, logs all transactions, and produces standardized outputs. This would move the team away from constant data quality cleanup and toward higher-value activities. Success is defined by having a clear, singular answer for customer onboarding status and bill retrieval health, moving away from the current situation where multiple systems provide conflicting information.

## Customer The customer is a specialized team within an energy data services company, responsible for processing and auditing utility bills for clients. Their core function involves data acquisition, account setup, and ensuring billing data from various vendors (like propane, water, and electric suppliers) is accurately captured and formatted within their systems. They operate at the intersection of client-specific rules, complex vendor billing structures, and internal data processing platforms. Their deep expertise is evident in their handling of nuanced scenarios, such as accounts with multiple meters for different commodities (e.g., cylinder liquid vs. propane) or locations billed under a single customer ID. ## Success The most significant achievement discussed is the strategic shift towards **utilizing a centralized, definitive "build template"** as the single source of truth for processing bills. This template, historically maintained in a legacy system, contains the approved account structure, including correct meter setups, units of measure, and observation types. The success lies in the development work to integrate this template concept directly into the new DSS (Data Services System), ensuring all automated bill processing is aligned with pre-established, client-approved configurations. This directly addresses a long-standing pain point where the system was creating inconsistent and erroneous data by inferring information, leading to operational delays. The move to enforce template adherence is seen as a foundational correction that will drastically improve data consistency and reliability. ## Challenge The primary challenge stems from the **system's previous behavior of autonomously creating new meters and line items**, overriding the established templates. This resulted in a proliferation of incorrect or duplicate data (e.g., creating a new meter in gallons when the template specifies thousand gallons/Kgal). This caused bills to become "stuck" in processing due to unit mismatches and created an overwhelming cleanup burden. The team is left manually sorting through numerous active and inactive line items to find the correct one for data entry. A critical sub-challenge is the inability to permanently delete the clutter; they can only inactivate items, which still linger in the system and are sometimes incorrectly used by the automation. This has made account management cumbersome and error-prone since the new system's launch. ## Goals The conversation outlines several clear goals for improving the product and service: - **Enforce Template Supremacy:** Halt the creation of new meters by the DSS for existing accounts. The system must conform to the existing build template, and any deviations should be flagged for human review rather than automatically applied. - **Implement Effective Cleanup:** Develop a mechanism to permanently delete inactive or erroneously created line items and meters, not just inactivate them. An automated process or a user-friendly interface within DSS to manage this cleanup is desired. - **Enhance Review Capabilities:** Integrate access to prior bills and their PDFs within the DSS interface. This historical context is vital for troubleshooting processing errors, verifying account details, and understanding billing trends over time. - **Complete Note System Integration:** Ensure all layers of notes from the legacy system-especially the specific **client-vendor notes** that contain unique processing instructions for particular client and vendor combinations-are fully visible and functional within DSS. - **Ongoing Alignment:** Establish a structured, weekly sync between the development and operational teams to collaboratively plan, review progress, and address emerging issues, ensuring the product evolves in direct response to frontline needs.

## **Introduction and Meeting Goal** The meeting was convened to establish a foundation for refactoring the Data Services (DSS) platform. The primary objective discussed was to make DSS more modular to accommodate new data sources and streamline processes, specifically for integrating Constellation Bills and a new external utility API. The session focused on identifying core tasks, understanding technical requirements, and planning the execution pathway for these integrations. ## **DSS Refactor: Core Objectives and Vision** The central goal of the initiative is to enhance the modularity of the DSS platform. This refactor aims to create a more flexible architecture that can easily integrate new data ingestion sources without disrupting existing workflows. The vision is to build a system where different data pathways can coexist, allowing for services to be added or bypassed as needed, ultimately making the system more maintainable and scalable. - **Make DSS more modular:** The refactor is intended to decouple services and create distinct pathways for processing bills from different vendors, which will simplify future integrations and maintenance. - **Accommodate new data sources:** The immediate driver for the modularity work is the need to seamlessly onboard data from Constellation Bills and a new external utility API, moving beyond the current web download methods. - **Maintain existing functionality:** A key principle is that the new architecture must not break or require major changes to the existing flows for current data sources, ensuring stability during the transition. ## **Constellation Bills Integration Strategy** A significant portion of the discussion was dedicated to planning the integration of bills from Constellation. The approach involves fetching XML and PDF data via an official API and mapping it into the existing DSS data structure. - **Data acquisition via API:** The plan is to pull XML and PDF bill data directly from Constellation's API, moving away from manual downloads. This requires understanding the API's authentication, endpoints, and the schedule for bill availability. - **Critical unknowns to resolve:** Several key questions were identified that need answers from the vendor or internal teams, including: the specific account identifiers needed for API requests, how billing cycles vary per client, and the exact timing for when bill data becomes available through the API. - **Processing and mapping flow:** Once retrieved, the XML data will need to be transformed and mapped to the existing DSS schema. The PDFs will be stored in blob storage. After this mapping and storage step, the existing DSS validation and processing flows would be utilized. - **Delegation and existing work:** It was noted that preliminary mapping work between Constellation's XML and the DSS structure has already been explored by another team member. This work can be leveraged and potentially delegated to other developers to accelerate progress, with a focus on code review and guidance. ## **External Utility API Integration Details** The integration of a new external utility API presents a similar but distinct challenge. This integration will be triggered via webhooks and involves processing JSON data extracts alongside PDFs. - **Webhook-driven initiation:** Unlike scheduled API calls, this integration will rely on webhook notifications to signal when new bill data is available, prompting the system to fetch the relevant information. - **Authentication and client scope:** Access to this external API will require managing credentials, such as API tokens. The rollout will be phased, starting with a limited set of bill-pay customers to validate the integration before scaling. - **Data transformation task:** The core technical task is to map the JSON output from this external API to the standard DSS data structure, similar to the XML mapping required for Constellation. - **Coexistence with current system:** A crucial point was that bills from this new source will still need to create bill records within the DSS and related legacy systems initially, as the platform is not yet ready to fully decouple from them. ## **Refactoring Approach and Technical Implementation** The conversation delved into the technical strategy for implementing these new services within DSS, clarifying that the "refactor" might be more incremental than initially envisioned. - **Services within DSS:** The agreed approach is to build the new API-fetching and data-mapping services as new components *inside* the existing DSS application, rather than as completely external systems. - **Leveraging existing flows:** The intention is for these new services to hand off data to the established DSS processing, validation, and storage flows after the initial source-specific mapping is complete. This minimizes changes to the core, tested logic. - **Re-evaluating refactor scope:** There was a realization that the foundational "refactoring" work needed to enable modular pathways might be less extensive than previously thought. The current plan is to proceed by building the new integration services first, and the necessary architectural adjustments will become clearer and can be addressed during that implementation. - **Retry mechanisms:** For both new integrations, robust retry logic will be necessary to handle cases where a bill is not immediately available via the API, ensuring no data is missed. ## **Ancillary Priority: Template Cleanup and Enforcement** Near the end of the meeting, a separate but important operational issue was raised concerning the management of templates within the system. - **Cleaning existing templates:** This was highlighted as a high-priority task because the proliferation of unused or poorly defined templates is directly contributing to increased operational costs and complexity. - **Enforcing template standards:** Alongside cleanup, there is a need to investigate how to more rigidly enforce template creation standards going forward. This would provide better governance and clarity on which parts of the system are generating specific templates. - **Understanding system impact:** The underlying goal is to gain a clearer understanding of system resource usage and costs by having a clean and well-documented set of templates.

## Customer The customer is a long-term client, onboarded approximately in August of the previous year, who utilizes the platform for critical energy data management and bill processing. Their operations involve handling complex utility data across multiple sites and vendors. They have experienced a prolonged period of instability with the product, leading to significant manual effort to clean and validate data. The relationship has been strained by frequent changes in their main points of contact within the service team, contributing to a sense of discontinuity and frustration. ## Success The most significant recent achievement has been the restoration of confidence through transparent communication and a committed roadmap for systemic improvement. The customer has explicitly acknowledged and appreciated the renewed effort to address long-standing issues. A key indicator of this restored trust is their strong desire for a dedicated, consistent point of contact from the product leadership team to ensure continuity and direct escalation. They are supportive of the strategic shift from reactive, one-off fixes to solving foundational platform problems that will benefit all users. ## Challenge The primary and most pressing challenge is the historical lack of accurate data within the system, which has forced the customer's team to engage in extensive, unsustainable manual cleanup for over a year. This core issue of data inaccuracy erodes trust and halts business growth, as evidenced by their hesitation to onboard new clients due to low confidence in the platform's output. Compounding this is frustration over perceived misalignment between the original sales promises and the product's delivered capabilities, as well as internal team turnover that has disrupted the partnership and communication flow. ## Goals The customer's objectives are centered on achieving stability, accuracy, and scalability. Their key goals include: - **Data Integrity and Automation:** Eliminating manual correction work by ensuring the platform delivers accurate, reliable data from the outset through improved validation and normalization processes. - **Systemic Resolution:** Moving beyond symptom-level fixes to address the root causes of data issues, thereby preventing a continuous cycle of new problems. - **Reliable Partnership:** Establishing a stable and expert point of contact to provide consistency in strategic communication and issue resolution. - **Confident Expansion:** Regaining the ability to securely and confidently onboard new clients and sites using the platform, enabling business growth. - **Clear Product Alignment:** Gaining a clear and updated understanding of the product's roadmap and capabilities to ensure future expectations are properly set and met.

## Customer The customer is a company implementing an energy data aggregation and automation platform (referred to as PluG) to streamline utility data collection for their commercial clients. Their background involves managing numerous commercial utility accounts across a wide range of providers, including large investor-owned utilities and smaller municipal providers. Their core operational workflow centers on integrating the platform's API to automatically pull utility statements and interval data, which is then parsed and stored in their internal database for analysis and reporting. The implementation involves cross-functional teams, including a project lead for the API integration and operational teams who will be primary users of the administrative dashboard. ## Success The most significant success anticipated from using the product is the complete automation of a previously manual and cumbersome data collection process. The platform enables the automatic, recurring retrieval of PDF utility statements and granular interval consumption data directly from utility provider portals once credentials are submitted. This eliminates the need for manual logins and downloads, saving substantial time and reducing human error. A major value-add is the system's ability to automatically pull up to 12 months of historical data for newly added accounts and the flexibility to request even deeper history on an ad-hoc basis. Furthermore, the product's design allows for efficient scaling, as credentials can be added individually through a dashboard, in bulk via CSV upload, or programmatically through the API, fitting seamlessly into the customer's planned automated workflows. ## Challenge The primary challenge identified is handling utility providers that are not currently supported by the platform's extensive but finite library. The customer's portfolio includes accounts with obscure municipal providers where they may have only one or few accounts, making it uncertain whether these providers will be prioritized for integration. This creates a potential gap in full automation, possibly requiring a separate, manual process to collect bills from these unsupported providers. Additionally, while the platform indicates at the provider level whether credential-based access is generally possible (`true`/`false`), the customer must still verify interval data availability at the individual meter level after enrollment, adding a step to their workflow. There is also some need for clarification on mapping their internal data structures to the API's response schema and understanding the full scope of available API monitoring and error logging capabilities. ## Goals The customer's key goals for using the platform are multi-faceted: - To fully automate the collection of monthly utility statements and interval data for the majority of their commercial client accounts. - To successfully integrate the platform's API into their own systems, creating a seamless, job-driven pipeline for requesting and receiving data. - To achieve comprehensive coverage by also developing a process for onboarding accounts from utility providers not currently supported by the platform, either through new template development or manual workarounds. - To utilize the platform for both standard, recurring data pulls and for ad-hoc requests for additional historical data or specific interval data. - To empower their internal operations and customer relationship teams with administrative access to the dashboard for visibility into data collection status and metrics.

## Summary ### API and Edit Functionality Development The discussion centered on the current state of an edit feature within an application, which is currently implemented as a read-only interface. This is a temporary state, as the necessary backend APIs for dynamic data fetching and updates have been identified but not yet fully integrated. The immediate focus is on stabilizing core functionality before enhancing the user interface with dynamic dropdowns and other interactive elements. - **Current read-only edit interface:** The feature displays data fields but does not allow user modifications. Key non-editable fields include IDs and specific line items, which are considered static reference data. - **Prepared backend for updates:** An update API endpoint has been created and is undergoing local testing to determine the correct data payload required for successful operations. - **Planned integration of supporting APIs:** Future work involves calling additional APIs, such as a Service Account API, to populate dynamic selection fields (e.g., for item types) and enable full editing capabilities. ### Template View and Data Display Issues Progress was reported on a template view page designed to display detailed file information. However, a recent code change introduced a regression that broke the automatic retrieval and display of key identifiers, such as Vendor ID and Client ID. - **Functionality regression:** A previously working feature that auto-populated vendor, client, and account data on the template view page is currently non-functional due to accidental code removal or alteration. - **Prioritization of core fixes:** The immediate plan is to restore this core data display functionality before moving on to further enhancements or refinements of the page. ### Deployment Pipeline and Environment Status The team reviewed the deployment status of various changes across development, test, and production environments. A general directive was given to promote any completed and tested work to production to prevent backlog accumulation in lower environments. - **Limited production deployments:** Most recent changes, including those for the discussed edit functionality and other tickets, are currently only deployed in the test environment. - **Specific updates in test:** Recent test deployments include fixes for two FTC Connect tickets-one related to BD enrollment and another concerning page reload behavior-as well as changes related to caching mechanisms. - **Push to production:** There is a clear intention to deploy any qualified changes from the test environment to production promptly to keep environments synchronized and deliver finished work. ### Administrative and License Assignment An administrative action was taken to resolve a software licensing issue, ensuring team members have the necessary access levels for data visualization and reporting tools. - **Power BI license upgrade:** A team member was assigned a Power BI Premium per User license to address access needs, supplementing an existing Pro license. - **Dual license coverage:** The user was intentionally kept assigned to both license tiers temporarily to guarantee uninterrupted access and full functionality while the new license assignment is validated.

## Summary The meeting primarily focused on reviewing urgent operational priorities, particularly clearing past-due invoices for key clients, addressing technical API alignment issues, and managing vendor performance concerns. The discussion emphasized rapid escalation and resolution of payment processing bottlenecks to prevent client relationship issues. ### Urgent Invoice Processing and Emergency Payments Immediate action is required to process a backlog of past-due invoices for major clients, with several flagged for emergency payments to avoid late fees and service disruptions. - **Victor and Extension backlog clearance:** There is a significant queue of past-due invoices for clients Victor and Extension, with many due dates already passed. For Victor, 145 bills are pending, with 28 past due and 64 due within 10 days. A similar situation exists for Extension, with 17 past due and 74 due soon. The team plans to manually review and initiate emergency electronic payments for applicable charges this morning to ensure same-day processing. - **Critical clients requiring special attention:** Specific high-priority clients like PNB and Royal Farms were highlighted due to their strict policies and propensity to impose heavy late fees. For instance, an electric bill for PNB was identified as needing immediate emergency payment to prevent service shut-off. - **Process for handling discrepancies:** A method for filtering and reviewing invoice discrepancies was discussed, particularly for "total charges mismatch" errors. The approach involves filtering out discrepancies greater than $1,000 for manual review, as smaller amounts are often related to credits or minor adjustments from previous bills. ### Technical Adjustments and API Integration Technical misalignments in data pipelines and ongoing work to enforce system templates were reviewed to reduce recurring processing errors. - **PayCleary API date field alignment:** A misalignment was identified where incorrect dates are being pulled from the PayCleary API for certain fields, such as virtual credit card interchange information. The core issue is ensuring the system captures the correct "submitted date" to align with receipt dates, which is crucial for accurate processing. - **Enforcing account templates to fix recurring errors:** To address persistent errors like unsupported "Units of Measure" (UoM) and mapping issues, the team is moving away from one-off fixes. The new strategy involves enforcing standardized bill templates for each account, which is expected to systematically resolve these common slipping points. ### Vendor Management and SLA Challenges Performance issues with a key payment vendor, Ascension, were discussed, focusing on their inability to meet SLAs despite claims of sufficient capacity. - **Escalating unresolved check payments:** There is a list of issued checks for Ascension that are still outstanding and available for cancellation and re-issue electronically via the vendor portal. Despite the vendor stating the checks are "unavailable," internal review shows the electronic payment option is often still viable, requiring direct intervention to reprocess. - **Addressing chronic SLA failures:** Although Ascension claims to have adequate staff and can handle increased volume, they consistently fail to meet SLAs for escalated, due payments. A communication gap exists where the team's willingness to pay extra for guaranteed priority processing is not being actioned by the vendor. A direct call was scheduled to reiterate this priority and resolve the disconnect. ### Internal Workflow and Resource Planning The team coordinated on internal task handovers and reviewed the status of a major client onboarding project. - **Handover for upcoming time off:** With team members taking time off, a brief handover was arranged to continue the daily review and approval of internal change requests, such as mapping and UoM adjustments, to avoid workflow disruption. - **Follow-up on Ascension account mapping:** An ongoing project with client Ascension involves mapping a large number of accounts. While progress has been made (from 100 to 43 remaining), the final list of 43 accounts has not yet been received back. Additionally, a separate review of 280 "arriving bills" was noted as pending action.

## Summary The meeting focused on resolving a critical billing and payment issue with Google Cloud that recently led to a service interruption. The core problem was a disconnect between Google's automated invoice delivery and the company's automated invoice processing system, compounded by inadequate internal oversight of the cloud spending contract. The discussion centered on diagnosing the root causes, implementing immediate manual safeguards, and defining a path toward a fully automated, reliable process. ### Root Cause Analysis: Why the Service Was Interrupted The service suspension occurred because invoices were not being paid on time, but the underlying issue was a failure in communication between the two systems. Google's invoices were being sent to an unmonitored, automated email address (`invoice@constellation.com`) that could not be verified by Google's system, causing a breakdown in the official distribution channel. Furthermore, the internal team responsible for administering the cloud contract and its funding in the Asset Suite 9 system was not properly set up or actively monitoring the contract's balance, so no one was alerted when the funding was depleted or when invoices were rejected. - **Unverifiable Invoice Email Address:** The primary technical hurdle is that Google requires a verified email address to send invoices, but the company's `invoice@` address is an unmonitored mailbox used solely for automated processing. It cannot complete a manual verification step, so invoices were not being formally delivered through Google's system. - **Lack of Internal Contract Oversight:** Administratively, the correct personnel (Sunny and Faisal) did not have access to the Asset Suite 9 system where the purchase order (PO) and its funding are managed. Without this access, no one was tracking the contract's consumption or could react when the PO ran out of funds, which caused new invoices to be rejected by the internal system even if they were received. ### Interim Solution: Manual Processes for Immediate Reliability To prevent another interruption while a permanent fix is developed, the team agreed on a set of manual steps to ensure invoices are seen and paid. The key is to leverage Google's capability to send invoice notifications and copies to individual, verified human administrators. - **Updating Google Cloud Payment Contacts:** Faisal confirmed he has billing administrator privileges in the Google Cloud console. He updated the payment profile to include himself and Sunny, ensuring both will receive direct email notifications for all future invoices and any critical account alerts (e.g., past-due notices). - **Manual Invoice Submission:** As a temporary workflow, Faisal will take responsibility for receiving the invoice notifications from Google and manually forwarding each invoice PDF to the `invoice@` address so it can be ingested into the Oracle payment system. This ensures payments are initiated even though the automated channel is broken. - **Validating Invoice Data:** The team confirmed that recent Google invoices do contain the necessary PO number, which is crucial for the internal system to match the invoice to the correct contract and approve it for payment. This was verified during the call by checking a sample invoice. ### Path to Full Automation: Verifying the Automated Email Address The long-term goal is to restore the fully automated handoff from Google's billing system to the company's Oracle system, eliminating manual touchpoints. The sole obstacle is the verification of the automated `invoice@` email address. - **Google-Side Force Verification:** The Google account representative is actively pursuing a "force verification" of the `invoice@` address through internal collections and billing support teams. If successful, Google's invoices would flow directly to the automated mailbox without requiring manual intervention from the company's side. - **Contingency Planning:** If force verification is not possible, the company would need to explore technical solutions, such as having the IT team temporarily configure access to the `invoice@` mailbox to complete the verification, though this was noted as a less ideal path. ### Ongoing Contract and Financial Management Beyond invoice delivery, the meeting highlighted the need for proactive financial management of the cloud contract to avoid future "insufficient funds" scenarios, even if invoices are being paid. - **Ensuring Proper Contract Administration:** It was stressed that Sunny and/or Faisal must be granted administrator access to Asset Suite 9. This access is required to monitor the contract's remaining value, approve increases in funding, and receive system alerts if invoices are rejected due to an exhausted budget. - **Proactive Funding Monitoring:** The team acknowledged that the contract's annual funding estimate may not match actual usage. Without active monitoring, a surge in cloud usage could deplete the PO faster than anticipated, leading to invoice rejections and potential service disruption, even if the invoice delivery problem is solved. This requires a separate, ongoing oversight process.

## Summary The meeting focused entirely on presenting a technical solution for cleaning a specific data column that contained inconsistent formatting. The core of the discussion was a step-by-step walkthrough of an automated method to extract clean date information from the problematic source data. ### The Data Cleaning Solution A specific formula-based approach was identified to efficiently clean the target column and extract usable date information. - **Using the `TEXTBEFORE` Function:** The proposed solution involves creating a new column and using a formula, specifically `=--TEXTBEFORE(...)`, to parse the original cell content. The formula is designed to remove all characters that appear after a specific delimiter (a space and another character), effectively isolating the relevant date portion that precedes it. - **Handling the Numerical Output:** After applying the formula, the result may initially appear as a raw serial number (e.g., 45370). This number is correctly identified as the date's underlying numerical representation within the spreadsheet software and simply needs to be reformatted. - **Final Formatting for Presentation:** The final step to achieve a human-readable date is to change the cell format of the new column to a "Short Date" format. This instantly converts the serial number into a standard date display (e.g., 03/14/2024), resulting in a clean, consistent column ready for customer-facing reports or further analysis. This method was presented as a means to significantly automate the data preparation workflow, ensuring more reliable and presentable data for end-users.

## **Overview of the Report and its Purpose** The meeting centered on analyzing and improving a daily financial report used to track client payment transactions. This report, sourced from the PayClearly system, is the de facto system of truth for monitoring how many bills are paid on behalf of clients via various methods-specifically ACH, check, and virtual card (V-card). The primary objective of this analysis is to accurately answer recurring client inquiries about their monthly payment activity, broken down by payment method and associated dollar values. - **Purpose and Client Context:** The report is critical for providing clients with transparent, monthly summaries of payment volumes and values. Clients frequently ask for these figures to reconcile accounts and understand transaction flows, particularly concerning checks, which can be a pain point due to potential delays and associated late fees. - **Current Methodology:** Historically, the team has been generating these summaries by filtering the data based on the invoice's "Due Month." This method was established to fulfill client requests but has inherent flaws, as it doesn't accurately reflect when the payment processing work was actually performed. ## **Identification of a Critical Flaw in Current Reporting** A significant flaw in the existing reporting logic was identified: using the "Due Month" as the primary filter does not accurately represent the company's actual processing activity within a given month. - **The Core Issue:** The "Due Month" on an invoice does not correlate to when the payment was processed. Invoices due in one month may be processed and paid in a subsequent month, especially when catching up on backlog or handling early payments for future dues. Relying on due date leads to misrepresenting monthly activity counts and financial figures reported to the client. - **Impact on Data Accuracy:** For example, showing check transactions for the month of June based on due date is misleading if those checks were actually processed and issued in July or August. This discrepancy means clients are not receiving a true picture of the work completed in a specific period. ## **Proposed Shift to a Process-Centric Date Metric** The discussion concluded that the reporting must shift from using "Due Month" to a date metric that reflects when the payment was actually processed to provide an accurate picture of operational activity. - **New Target Metric:** The consensus was to use the date a payment file was created (the "Created" date timestamp in the report) as the correct filter for monthly summaries. This aligns the reported numbers with the actual work performed by the team in that calendar month, irrespective of the original invoice due date. - **Inclusion of "Tracking" Status:** To fully capture all activity, it was agreed that payments in both "Processing" and "Tracking" statuses should be counted. "Tracking" represents work that has been initiated and is awaiting bank confirmation, which then flips to "Processing"-thus, both statuses constitute completed operational effort. ## **Technical Hurdle: Data Format and Excel Manipulation** A major technical obstacle to implementing this solution is the non-standard format of the "Created" date field in the raw PayClearly report. - **Format Problem:** The "Created" field contains a timestamp in a string format that Excel does not automatically recognize as a date (e.g., "20231115 06:28:00" without standard date separators). This prevents the direct use of Excel's pivot table and date filtering functions to roll up transactions by month. - **Explored Solutions:** Potential solutions discussed involve data cleaning within Excel, such as: - Using text functions (e.g., `LEFT`) to extract just the date portion of the string into a new column. - Attempting to force a format change via Excel's built-in date formatting tools, though initial attempts were unsuccessful with this specific data structure. - Creating a helper column with a cleaned date that can be used as a proper field for monthly aggregation in pivot tables. ## **Strategic Implications and Path Forward** The conversation underscored the importance of accurate reporting for client trust and internal clarity, while acknowledging the need for a practical, if temporary, solution. - **Client Communication and Caveats:** It was noted that continuing with the "Due Month" method is acceptable only if the inherent inaccuracy is clearly understood and communicated as a caveat to clients. However, the goal is to move away from this acknowledged error to a more precise reporting standard. - **Manual Work and Next Steps:** Until a technical fix for the date formatting is implemented, the team will continue to manually compile the monthly figures-a labor-intensive process that involves sorting and counting transactions based on the "Created" date. The immediate next step is to develop a reliable method to parse the PayClearly timestamp into a usable Excel date format to enable automated, accurate monthly summaries.

## Summary The meeting centered on a critical review of the operational challenges faced throughout 2025 and the strategic roadmap for 2026, with a core emphasis on shifting from reactive problem-solving to proactive, continuous improvement. ### Opening Philosophy: From Decision to Action The discussion was framed by a metaphor highlighting the difference between deciding to act and actually executing, setting the tone for the entire meeting. The key takeaway was that identifying problems is not enough; the team must be empowered and expected to bring forward potential solutions alongside the challenges to drive meaningful change and reduce daily "fire drills." ### Review of 2025: A Year of Reactive Challenges The past year was characterized by significant growth that exposed systemic weaknesses, forcing the team into a reactive mode to maintain operations. Several major pain points were successfully addressed but often as band-aid solutions. - **AI Implementation for Bill Ingestion:** OpenAI was integrated to help extract information from bills and push them through the ingestion process, though this required untangling legacy data structures. - **Application and UI/UX Improvements:** Substantial work was done to adapt the application's build templates and user interface to handle variations across clients, vendors, and service types, ensuring data flowed correctly from upstream systems. - **Focus on Data Accuracy and Guardrails:** A major effort was initiated to design, implement, and test data validation guardrails, aiming to prevent the same errors from recurring and consuming development resources on repetitive hot fixes. - **Uncovered Systemic Complexities:** The reactive work revealed deep interdependencies between multiple subsystems (e.g., UDM, DSS, FPG), which often operate like separate platforms. This complexity, compounded by legacy, on-premise systems incongruent with cloud applications, created scalability limits and significant compliance overhead. ### Strategic Direction for 2026: Optimization and Empowerment The vision for the coming year is to build on the lessons of 2025 by optimizing foundational processes, thereby freeing up capacity to work on value-added features rather than just operational table stakes. - **Shift from Reactive to Proactive:** The goal is to move beyond firefighting by better planning for known challenges, documenting "the new normal" for workflows, and understanding that not every issue has a technological solution-some will require updated operational processes. - **Enhance Customer-Centricity Internally:** While clients only see the final output, internal teams must adopt the customer's perspective to streamline the end-to-end process, from timely bill download to payment. - **Centralize and Systematize Knowledge:** A critical initiative is to codify fragmented institutional knowledge into living, version-controlled documentation to eliminate ambiguity and accelerate onboarding and problem-solving. ### Key Initiatives for the 2026 Roadmap Specific projects were outlined to address the core challenges identified, focusing on data integrity, self-service, and streamlined client onboarding. - **Doubling Down on Data Accuracy:** The focus will be on strengthening guardrails using historical human-validated data as a foundation, rather than relying solely on AI interpretation, and creating better "interpreters" between systems like DSS and UDM to align data contexts. - **Self-Service Data & Reporting:** To stop the bottleneck of creating custom reports, a flexible API will be provided, allowing clients to access their data directly. This will be followed by a drag-and-drop report builder, empowering customers and freeing the development team from endless custom report requests. - **Streamlining and Formalizing Onboarding:** A major push will involve implementing tools like automated Gantt charts synced with CRM data to visualize timelines and dependencies. A formal "wizard" for AP file mapping will require clients to sign off on a specific data format early, with any subsequent changes triggering a formal change control process to manage expectations and scope creep. ### Process Evolution: Managing Requests and Priorities New mechanisms will be established to handle the influx of ideas and issues from both internal teams and clients in a transparent and prioritized manner. - **Structured Intake Channels:** All feedback-bug reports, feature requests from Client Success Managers (CSMs), internal operational needs, and sales input-will be funneled into centralized systems (HubSpot for clients, dedicated forms/channels for internal teams) instead of disparate emails and chat messages. - **Transparent Prioritization Framework:** A clear process will be developed to assess, prioritize, and communicate the status of requests. This includes defining severity levels (e.g., P0 for critical bugs) and ensuring all teams understand how priorities are set based on impact to the platform, internal processes, and clients. - **Setting Firm Client Expectations:** The team will adopt an enterprise-standard approach where requirements agreed upon during onboarding are binding, and late changes are formally documented and assessed for impact on timeline and resources, protecting team bandwidth. ### Highlights from Q&A The open forum addressed specific operational concerns and communication plans. - **Standardization of Time Zones:** The lack of a standard time zone reference across international systems and vendor cutoffs (like UTC-based payment files) was acknowledged as a significant pain point. The solution will involve clarifying which systems use which standards and investigating the possibility of more flexible, on-demand data refreshes where feasible. - **Internal and Customer-Facing Communications:** A regular release schedule is planned, complemented by short internal training videos (e.g., via Loom) for new features. These resources can then be adapted by CSMs and sales for client-facing discussions, improving stickiness and demonstrating ongoing development.

## Summary The meeting centered on addressing a critical technical issue involving duplicate data imports within a system referred to as UBM, which is consuming excessive operational resources and affecting a specific client. ### The Core Technical Issue A significant technical malfunction was identified where a data import process created duplicate entries from a single source file. The discussion focused on the symptoms and immediate observations of this failure. - **Duplicate imports of a single file**: The system erroneously processed the same received file multiple times, leading to redundant data entries. This was confirmed as the primary symptom, narrowing the investigation away from the possibility of multiple source files being sent. - **Abnormally long processing time**: One of the file processing jobs was reported to have taken one hour to complete, which was flagged as an excessively long duration and a potential indicator of an underlying system performance or logic error. ### Operational Impact and Urgency The issue was framed as a high-priority problem due to its direct negative impact on daily business operations and client relations. - **Diversion of critical resources**: The problem is consuming a substantial amount of time for operational staff, who need to focus their efforts on core activities like processing and paying bills to maintain workflow momentum. - **Exacerbation with a key client**: The problem has manifested specifically for a client named Victor, who is already identified as a "problem client." Ensuring system reliability for this client is a particular concern to prevent further complications. ### Investigation Status and Next Steps The conversation concluded with an acknowledgment that the root cause was not yet determined and a plan for collaborative resolution. - **Undetermined root cause**: The team explicitly stated that the precise source of the bug or system failure had not been identified during the meeting, confirming the issue was still in the diagnostic phase. - **Commitment to a team-based solution**: It was agreed that solving this problem requires a coordinated team effort to delve deeper into the system's behavior. A follow-up plan was suggested for a team member to provide a recorded audio summary of any conclusions or findings after further investigation.

## Customer The customer operates in a data-intensive operational environment where managing and reconciling billing and account information from multiple systems is a core function. Their role involves ensuring the accuracy and consistency of customer account data across various platforms, including UBM for lab reports and a centralized Data Services repository. The background indicates a significant reliance on manual reporting processes, cross-referencing data from disparate sources like "late alive bills" and billing accounts reports to maintain a coherent view of customer statuses, particularly for critical operational reviews and customer success management. ## Success The most significant achievement has been the establishment and adoption of a single, authoritative "source of truth" for all account data. This centralization, primarily within the Data Services master accounts file, has successfully replaced a chaotic landscape of numerous conflicting reports. This consolidated source is now being leveraged for multiple critical use cases, fundamentally shifting the workflow from one of constant reconciliation and doubt to a more structured and reliable starting point for all downstream analysis and reporting. This move has provided a much-needed foundation for consistency and has begun to reduce the time spent arbitrating between different data sources. ## Challenge The primary ongoing challenge is the persistent issue of data fragmentation and duplication, especially concerning account records. A significant pain point is the misalignment between systems; for instance, accounts marked as "closed" in one platform may continue to generate invoices or appear in active reports elsewhere. This necessitates tedious manual cleanup efforts that are often reactive rather than proactive. Furthermore, the process of generating necessary reports, such as weekly summaries for customer meetings, remains largely manual. This creates a bottleneck, consumes considerable time, and introduces the risk of errors as individuals must manually "slice and dice" data from the central source to meet specific, evolving requirements. ## Goals - To fully automate the generation of key reports, particularly the weekly summary for customer reviews, by codifying the existing manual steps into a reliable, scheduled process. - To achieve a complete and reliable merge between the lab report data and the central billing account data, eliminating the need for manual comparison and duplicate hunting. - To enhance data quality and proactive error detection by enabling all system validations for a targeted set of key customers, which will help catch billing inaccuracies like usage spikes or incorrect decimal placements. - To implement a sustainable process for maintaining data hygiene, ensuring that once accounts are cleaned up or closed, this status is consistently reflected across all systems to prevent future discrepancies. - To evolve the centralized reporting into an actionable tool that not only provides data but also helps teams manage customer issues and track progress over time.

## Core Issue: Build Template System and Data Enrichment in DSS The central challenge discussed is the rigidity and drift within the Data Services System's (DSS) build template system, which is used to structure and enrich invoice data. The legacy system's dependency on rigid templates creates downstream problems in Utility Bill Management (UBM), particularly the automatic creation of new virtual accounts and templates when incoming invoice data doesn't perfectly match historical definitions. The meeting explores strategies to refine the template matching logic, enforce data integrity on critical fields, and execute a systematic cleanup of accumulated template data. ### The Problem with Current Build Templates The existing system for matching invoices to predefined build templates is overly rigid and prone to creating duplicate data, leading to operational inefficiencies. - **Rigid Matching Logic:** The current system requires exact matches on five key fields (like service address and rate code) to map an invoice to a historical template. Slight variations (e.g., "GS" vs. "General Services" for a rate code) cause a match failure, triggering the creation of a new, often redundant, template and virtual account in UBM. - **Template Proliferation:** This matching failure mechanism has likely led to the creation of a large number of "one-off" templates. This proliferation becomes unsupportable and creates significant manual cleanup work downstream, as operations teams must reconcile the mismatched data in UBM. - **Downstream Impact in UBM:** The core business impact is felt in UBM, where the creation of new virtual accounts due to template mismatches results in mapping errors and requires extensive manual intervention from operators to correct. ### Proposed Solution: Refined Template Matching & Enforcement The proposed strategy involves loosening the criteria for template *matching* while tightening control over the *enforcement* of critical data fields within a matched template. - **Simplify Matching Criteria:** The suggestion is to distill the matching logic down to three core, stable identifiers: **Client, Vendor, and Account Number**. This broader matching approach should capture more invoices correctly under the appropriate historical template, reducing the creation of new ones. - **Enforce Critical Template Fields:** Once a template is matched, certain fields within it must be enforced as immutable to ensure data consistency. The **observation/service type for usage and cost data** (e.g., "use cost") is considered non-negotiable, as changing it affects billing calculations. Other fields, like descriptive captions for line items (e.g., "State Tax"), can be more flexible and updated based on the invoice content. - **Utilize LLM Context More Effectively:** The Large Language Model (LLM) used in the Intelligent Processing System (IPS) could be better leveraged. It should be provided with a much narrower, more relevant set of historical data (filtered by client/vendor/account) to make its enrichment decisions, rather than a broad set of all client data. ### The Critical Need for Historical Data Cleanup Cleaning up the existing corpus of historical templates and line item definitions is identified as a prerequisite for improving future automated processing. - **Foundation for LLM Accuracy:** The historical data serves as the primary reference for the LLM during the data enrichment step. Inconsistent, duplicate, or "noisy" historical data directly leads to poor LLM predictions and perpetuates downstream errors. - **Targeted Cleanup Activities:** An audit is needed to identify and merge duplicate templates (e.g., multiple "propane" line items) and eliminate inactive or erroneous service item descriptions. Reducing the problem space for the LLM by cleaning the reference data will increase processing accuracy. - **Progressive Filtering Strategy:** The system currently uses a progressive fallback method for matching: it first tries to match on the most specific criteria (Commodity + Vendor + Account), then broadens to Vendor + Commodity if needed. The goal is to strengthen the initial, most specific match by ensuring the underlying data is clean. ### Technical Implementation and System Flow The discussion clarified the two-step processing flow within DSS and how the template system integrates. - **Step 1 - LLM Initial Classification:** The first step involves the LLM analyzing the raw OCR output from an invoice to extract key entities like client, vendor, account number, and commodity type. This step establishes the initial context without relying heavily on historical templates. - **Step 2 - Historical Data Enrichment:** The second step uses the identifiers from Step 1 to query for relevant historical templates and line items. The system then attempts to align the LLM's extracted line items with the historical patterns. The success of this step hinges on the synergy between the textual description of line items on the new invoice and how they were described in the historical data. - **Current Data Scope is Too Broad:** A key finding is that the system may be sending too much historical data to the LLM for context. Instead of sending all service items for a client, it should send only those relevant to the specific **client-vendor-account (and commodity)** combination identified in Step 1, making the LLM's task more precise. ### Next Steps and Strategic Considerations The meeting concluded with specific investigative and tactical actions to address the outlined problems. - **Quantify the Problem:** The first action is to analyze the database to determine how many new templates and line items have been created by the automated system over the past several months. This data will reveal the scale of the template proliferation issue. - **Implement Refined Data Filtering:** The technical team will adjust the "Step 2" enrichment API call to filter historical data based on the specific client-vendor-account combination, providing a more targeted context to the LLM and improving match accuracy. - **Plan a Systematic Cleanup:** A strategy for programmatically identifying and merging duplicate or erroneous templates and line item descriptions needs to be developed. This cleanup is essential before the system can safely begin learning from more recent data. - **Re-evaluate the Historical Data "Freeze":** The system currently only uses historical data created before a specific "go-live" cutoff date (e.g., June 30, 2025) to avoid learning from its own mistakes. Once the data is cleaned, a cautious, client-by-client approach to updating this historical data window can be considered to allow the system to adapt to legitimate new patterns.

## Summary of the Meeting ### **Critical Client Issue: University Billing Data** The discussion opened with a review of a significant ongoing issue for a major university client. The core problem is that the client's utility usage data is not being correctly split and displayed in the platform, stemming from a legacy billing setup where multiple campus buildings are consolidated under a single bill. This has led to a year of frustration for the client, as promised data views have not materialized. The team acknowledged this is not a system bug but a fundamental gap in processing "summary bills." The immediate challenge involves manually correcting extensive historical data across many buildings, but the larger concern is ensuring a sustainable, accurate process moving forward. This case raised a red flag about the potential for other clients facing similar unmet expectations from sales promises. ### **Review of Recent Development & System Challenges** The conversation shifted to preparing for an internal review, focusing on development accomplishments and persistent systemic challenges. Key achievements from the recent period were highlighted, including resolving critical **DSS capacity issues**, implementing numerous hotfixes, and adding important UI improvements and data tracking features. However, a major portion of the discussion was dedicated to the deep-seated challenges within the technology stack. The systems were originally architected for a different business model (postpay) and now struggle with the demands of prepay operations, leading to tight SLAs and constant firefighting. Furthermore, the codebase has significant technical debt, with logic that is haphazard and doesn't scale. This results in a fragile foundation where solving one problem often uncovers several more, consuming immense developer time for troubleshooting rather than building new capabilities. ### **Vision and Roadmap for the Upcoming Year** The strategic focus for the upcoming year centers on operational stability and reducing friction, rather than flashy new features. The primary goal is to **reduce reliance on legacy systems and architecture** to alleviate chronic pain points and create a more scalable foundation. A key part of this effort is the planned consolidation and sunsetting of outdated, redundant reports. The roadmap is also heavily focused on optimizing core processes: streamlining account setup and data ingestion workflows, critically reviewing and adjusting validation logic and error handling, and significantly improving internal and external documentation. The ultimate aim is to reach a baseline where the platform reliably meets the fundamental expectations it was sold on, before expanding its feature set. ### **Operational Improvements: Intake Process & Build Templates** A significant operational update was the development of a new, transparent intake system for requests and issues. This system provides a public URL where any stakeholder can submit items, which are then automatically populated into a prioritization board for the development team. This initiative aims to create visibility and manage expectations by clearly communicating how requests are evaluated and scheduled, acknowledging that not everything can be addressed immediately due to capacity constraints and system complexities. Separately, a major technical deep-dive occurred on **build templates**, which are crucial for accurate data mapping. A new internal view was demonstrated, revealing issues like duplicate templates and mismatched units (e.g., pounds vs. gallons) that cause downstream errors. The future state envisions a centralized, version-controlled template system that enforces consistency, dramatically reducing setup errors and manual correction work. ### **Strategic Data Initiatives and Vendor Integration** Looking further ahead, the discussion touched on strategic data projects necessary for future scalability. One key initiative involves enhancing master data management by integrating third-party utility vendor information (e.g., from Arcadia). The goal is to create a enriched vendor database that includes metadata such as authentication requirements (MFA), data availability, and typical performance. This knowledge would then be embedded directly into setup workflows and customer-facing interfaces, proactively guiding implementations and setting accurate expectations. This represents a move from reactive problem-solving to proactive, data-driven process design, which is essential for handling a growing and diverse customer base efficiently.

## **Summary** The meeting focused on resolving ongoing challenges in the payment reconciliation process between Medline and the Constellation team, facilitated by PayClearly. Key topics included establishing protocols for handling duplicate payments, clarifying the "mock bill" process, executing a detailed reconciliation of historical funding file discrepancies, and aligning on procedures for security deposits and new account onboarding. ### **Handling Duplicate Payments in Funding Files** A process was agreed upon to prevent funding duplicate payments, which had previously led to operational inefficiencies and reconciliation issues. - **Revised Process:** If a duplicate is identified in a funding file, the Constellation team will be notified, and a revised file will be requested instead of funding the duplicate items. This avoids the need to fund and later refund payments, streamlining the reconciliation. - **Communication Protocol:** Notifications for duplicate identification and cancellation will be sent to a specific distribution list, including the OPS email and key team members, to ensure clear and centralized communication. - **Turnaround Commitment:** The Constellation team committed to providing corrected files on the same day if issues are communicated in the morning, minimizing delays for other payments in the batch. ### **Clarification of the "Mock Bill" Process** The nature and purpose of the "mock bill" process were clarified, as it was identified as a primary source of duplicate payments in November. - **Process Definition:** A "mock bill" is not an estimate but an **interim payment of actual charges** captured from a utility portal or via phone when a detailed invoice is delayed. It is initiated within 10 days of a due date to avoid service disruption. - **Ideal Workflow:** When the actual, detailed invoice later arrives, it is processed in the system for analytics, and the interim record is archived. The system error in November occurred because this archival did not happen, causing both the interim and actual invoices to be paid. - **Strategic Use:** The process is intended to be a sparingly used exception for critical situations, not a standard rule, to maintain clean payment records. ### **Reconciliation of Historical Funding File Discrepancies** A detailed exercise is underway to reconcile outstanding differences in payment files, categorizing discrepancies to determine necessary funding adjustments. - **Categorizing Discrepancies:** Differences fall into three main categories: - **"Missed" Files:** Payments that were short-paid or deleted by Medline, often due to prior direct payments to the vendor or suspected duplicates. - **"Sample" Files:** Early test files mistakenly included in the reconciliation analysis that require no funding action. - **Large Short Payments:** Instances where a significant portion of a file was not funded, requiring line-by-line validation. - **Three-Step Validation:** For each discrepancy, the team will: 1) confirm if Medline paid directly, 2) verify if PayClearly also paid, and 3) check with the utility to see how the payment was applied to the account. - **Next Steps:** The Constellation team will complete a line-item review of all notes to produce a "true-up" analysis, identifying exactly which payments require funding or correcting entries to bring accounts to a zero balance. ### **Addressing Security Deposits and Account Mapping** The reconciliation exercise uncovered a need for standardized procedures for handling security deposits and correcting facility account mappings. - **Security Deposit Process:** A dedicated balance sheet account is used for security deposits paid to utilities and refunds received. - The team will provide specific general ledger account instructions for applying both deposits and refunds. - For new or large deposit requests (e.g., over $100,000), the Constellation team's assistance will be leveraged to potentially negotiate waivers. - **Account Alignment:** Instances were found where utility accounts were mapped to the incorrect internal facility. Instructions for correcting these mappings or adding new accounts should be sent to the designated operations contacts. ### **Onboarding New Accounts from an Acquisition** The process for onboarding utility accounts from a recent acquisition (Microtech) was discussed to ensure no service disruptions. - **Urgency:** With payables transitioning imminently and billing cycles approaching, there is a risk of disruption if accounts are not onboarded promptly. - **Action Plan:** Medline will forward the account details (approximately nine facilities) for quick onboarding. If necessary, Medline will make interim payments directly to utilities while the onboarding is completed, with both teams committing to clear communication on the process status.

## Summary The meeting focused on progress updates across several development and reporting workstreams, followed by the assignment of a new task aimed at automating a manual process. ### Progress on Automated Reporting and Data Management The discussion centered on the management and communication of automated data refreshes for critical reports. - **Tracking and Inactive Account Reporting:** A tracking system for Data Services (DSS) has been established. An "inactive report" was created and shared to help filter out inactive vendor and client accounts from the master dataset. - **Setting Data Refresh Expectations:** A key point addressed was the refresh schedule for the master data used in reports. It is not real-time but refreshes on a scheduled basis (up to eight times daily) due to the large volume of data. The team agreed to clearly communicate this to stakeholders so they can manually refresh reports if they need the very latest information, managing expectations about data latency. ### Build Template User Interface Development Significant progress was shown on a new user interface (UI) for building templates, which allows users to search and view detailed account information. - **UI Functionality and Data Retrieval:** The developed UI enables users to select a client, which then dynamically populates the associated vendor and billing account numbers. Upon searching, the system retrieves comprehensive account data including service type, addresses, and related meter line items from the backend database. - **Feedback and Next Steps:** The interface was demonstrated and received positive feedback for being helpful. Immediate actions include pushing the current build to a testing environment and implementing minor labeling changes, such as renaming "billing account" to "account number" to avoid confusion with other terms in the system. ### Updates on Power BI and User Interface Enhancements Updates were provided on the completion of a Power BI report and enhancements to another application's filtering interface. - **Report Deployment:** A Power BI report was successfully updated and deployed, with the related ticket marked as complete. - **Filtering Improvements for Vendor Data:** For a separate task, a button was added to a UI to filter test vendor data, along with a "clear all filters" button. This functionality has been deployed to a development server and is awaiting testing and deployment to a preview environment, pending confirmation of the correct database connection string. ### Deployment Processes and New Task Assignment The conversation clarified deployment responsibilities and introduced a new automation project. - **Clarification on Deployment Authority:** It was confirmed that deployments to the FDG Connect environment follow a standard pipeline process and can be executed by any team member, not just a specific individual. - **Introduction of Late Bills Automation Task:** A new task was assigned to automate a manual process described in an email. The goal is to analyze and potentially automate the matching of data between DSS and another system (UVM), specifically focusing on late bills. The team member is to investigate what can be automated easily and determine if parts can be delegated, with a progress check scheduled for midday. ### Technical Clarifications and System Logic A technical question was raised regarding the underlying business logic governing the system's data relationships. - **Question on Service Type and Line Item Association:** A developer sought clarity on whether the logic defining which service types are linked to specific possible line items is stored in the database or defined within the application/API layer. The preliminary response suggested this logic is likely condition-based within the application rather than explicitly defined in the database schema, with an offer to share more details from the relevant web app and API.

## Customer The customer is responsible for energy management for a large campus comprising approximately 30 buildings. Their primary focus is on monitoring and controlling energy consumption across these facilities, as the cost per unit of energy is typically fixed through separate rate negotiations with suppliers. The role involves detailed tracking of utility usage at the individual building level to identify trends, implement efficiency measures, and manage operational budgets effectively. ## Success While the anticipated analytical capabilities of the platform have not yet been realized, the primary success lies in the thorough and detailed onboarding process. The customer has invested significant effort in providing comprehensive data, including mapping specific meter numbers to corresponding buildings and defining attributes for logical groupings (such as dormitories, academic buildings, and residential houses). This foundational work has created a clear and actionable roadmap for configuring the system once the core technical challenge is resolved. ## Challenge The most significant and persistent challenge is the platform's current inability to correctly process and display data from master utility accounts. For roughly 85-90% of the campus buildings, electricity is billed under a single master account from the supplier. Although the detailed invoice breaks down usage by individual meter numbers tied to specific buildings, the platform consolidates all this data under one umbrella account and location. This renders the system unusable for its core purpose: enabling month-to-month and year-over-year consumption comparisons for individual buildings. This fundamental disconnect has led to a year of frustration with no visible progress, causing the customer to disengage from using the platform entirely. Additional complications include occasional missed invoice capture without clear notification and the need for the solution to accommodate future changes in energy suppliers. ## Goals The customer's key objectives for using the platform are clear and directly tied to operational efficiency: - To analyze energy **usage** (not just cost) at the granular, building-by-building level. - To track and compare consumption metrics month-over-month and year-over-year for each specific building. - To utilize predefined building attributes to view aggregated data for logical groups, such as all dormitories or all academic buildings. - To have a reliable system that continues to function correctly even when the organization switches energy suppliers, ensuring consistent data visibility. - To eventually have historical data corrected and properly allocated to the correct building locations for accurate long-term trend analysis.

## Customer The customer is a large organization operating in the healthcare sector, managing a high volume of vendor payments. They have recently gone live with the payment automation platform and are actively using it to process hundreds of payments, with a strong preference for electronic payment methods (virtual card, E-check) over paper checks. Their internal teams are deeply involved in daily operations, pulling data directly from the platform to share with their own clients, indicating a need for accurate, real-time data synchronization. ## Success The most significant success has been the effective **automation of payment processing**, particularly for repeat vendors. The platform's system for credentialing and routing vendors for the first time, though it requires an initial investment of time, successfully sets up subsequent payments for faster, automated processing. This foundational work is creating efficiency for future payment cycles. Furthermore, the implementation of rules to prioritize payments based on due dates-and the ongoing development of a system to push reissued payments with past due dates to the front of the queue-demonstrates a collaborative effort to refine the service around the customer's core need: ensuring vendors are paid on time. ## Challenge The primary challenge centers on **data consistency and clarity in payment status reporting**. A critical discrepancy has been identified between the "cleared date" for payments returned via the API and the date displayed within the platform's user interface (PayClearly). This is causing confusion for the customer's team and their end-clients, as they see different information in different places. Initial analysis points to a potential timezone conversion issue between UTC (used in the API) and local time displays in the app, but it requires specific payment examples to diagnose fully. A secondary, related challenge involves the process and timeline for **reissuing failed or canceled payments**. When a payment method fails and needs to be reissued, it triggers a re-enrollment and verification process that is currently treated as a new setup task, taking up to five days. This timeline conflicts with the customer's expectation for a swift resolution, especially when the original payment is already past due. The current system does not systematically prioritize these reissue workflows over other pending payments, leading to potential delays in sending out the corrected payment electronically. ## Goals The customer's key goals for using the platform are: - To achieve complete, reliable, and transparent automation of their accounts payable workflow. - To maximize the rate of electronic payments (virtual card, E-check) and minimize the issuance of paper checks. - To have clear, consistent, and accurate data across all touchpoints-API, platform reports, and user interface-to support internal and external reporting. - To ensure vendor payments are consistently made by their due date, improving vendor satisfaction and operational reliability. - To scale payment volume confidently, with the assurance that platform capacity and processes can handle significant increases without degradation in service level or timeliness.

## **Customer** The customer in focus is a large enterprise client, likely within the healthcare or multi-site facility management sector, utilizing a comprehensive utility billing and data management platform. Their role involves overseeing complex portfolios with numerous locations and utility accounts, requiring accurate data aggregation, reporting, and financial reconciliation for energy spend and sustainability tracking. Their background indicates they rely on the platform not just for bill pay but for critical operational reporting, budgetary analysis, and meeting regulatory or internal ESG (Environmental, Social, and Governance) disclosure requirements. ## **Success** The most significant success achieved was the **identification and manual resolution of pervasive data quality issues** affecting critical consumption and cost reporting. For the customer's major portfolios (e.g., Hexpoal, St. Elizabeth, Munson), the root causes of reporting inaccuracies-such as double-counted usage lines, incorrect unit measures, and misclassified bills-were systematically diagnosed. A dedicated cleanup effort corrected historical data for the 2025 period, restoring confidence in the accuracy of location-level utility consumption and spend figures. This foundational work transformed a situation of unreliable data into a cleansed, actionable dataset, which is essential for their energy management and financial forecasting. ## **Challenge** The primary challenge revolved around **systemic data integrity and process reliability issues** that undermined trust in the platform's core functionality. Key problems included: - **Data Inconsistencies:** Persistent errors like double-counted usage, incorrect service dates for delivered commodities (e.g., propane), and bills being mis-categorized (e.g., full-service vs. supply-only) led to inflated or inaccurate consumption and cost reports. - **Reconciliation Complexity:** The bill payment and funding reconciliation process, especially involving emergency payments, was described as a "spaghetti" of interconnected files and dates. The lack of real-time data synchronization with the payment processor made manual, line-by-line reconciliation a daily, time-consuming burden for the customer's operations team. - **Unreliable Monitoring Tools:** Key customer-facing health checks, like the "Bill Health Report," were not considered a reliable source of truth due to issues with virtual account mapping and data lags, leaving the customer without a clear, automated way to identify missing bills or data problems. - **Communication Gaps:** There was a noted lack of proactive communication regarding system status updates (e.g., processing delays, feature outages) and missing data requirements (e.g., expired portal credentials), forcing the customer into a reactive "firefighting" mode instead of strategic management. ## **Goals** The customer's goals, as inferred from the discussions, are centered on achieving stability, automation, and self-sufficiency: 1. **Accurate and Automated Data Validation:** To have automated checks and validation rules within the platform that proactively flag data anomalies (e.g., usage spikes, missing bills) before they impact reports, eliminating the need for manual forensic analysis. 2. **Transparent and Proactive Communication:** To receive clear, timely notifications for any system issues, processing delays, or upstream data failures (like missing bills) through dedicated channels or in-platform alerts. 3. **Streamlined Financial Reconciliation:** To have a redesigned, intuitive payments interface that clearly separates normal and emergency payments, supported by better APIs from the payment processor to enable automated, accurate matching of funding requests and customer deposits. 4. **Self-Service Reporting Capabilities:** To move away from custom, hard-coded report builds and toward a future state where they can access all their data via a robust API or standardized data export (like a "Sheets" view), allowing their team to build the specific reports they need without ongoing development requests. 5. **System Stability and Feature Completion:** To see promised features (like multi-select vendor filters) delivered on committed dates and to have core platform stability so that their team can rely on it for daily operations without unexpected disruptions.

## Meeting Logistics and Scheduling Adjustments The primary focus was on coordinating meeting schedules and addressing an administrative oversight. - **Rescheduling a key meeting:** The meeting with a party referred to as "pay clearly" was rescheduled for the afternoon. While a preferred time was requested, there was initial confusion as the invitation was not received by one participant, indicating a potential communication gap in the calendar system that required a manual forward of the invite. - **Upcoming holiday coverage:** There was a brief acknowledgment of the upcoming Christmas holidays, with coverage plans being discussed to ensure support for an offshore team remains uninterrupted during the period. ## Operational and Administrative Follow-ups The discussion shifted to immediate email correspondence and a procedural compliance issue. - **Urgent email responses:** An immediate action was required to respond to an email from a colleague named George, highlighting a time-sensitive communication that needed attention. - **Training compliance concern:** A significant operational issue was raised regarding an individual who had not completed mandatory training. This was stated as an ongoing problem ("Just doesn't end"), suggesting a recurring challenge with ensuring team-wide adherence to required protocols.

## **Summary** The meeting consisted of two primary segments: an initial internal team sync focused on ongoing technical development tasks, followed by a strategic discussion in preparation for a crucial client call aimed at securing a major year-end deal. ### **Internal Development Updates** This section covered the status of various engineering and data-related projects currently in progress. - **Build Template System and Tracking:** Work is underway to add tracking for template creation, though a decision was made to continue allowing creations for now. The next major step is to develop a feature allowing operators to assign specific build templates to bills, which will be essential for data enrichment. A foundational UI page has been created to display structured JSON build template data, which will serve as a base for future features, including filtered views by vendor, client, and client account. - The immediate task is to finalize and deploy the tracking mechanism for template creation. - A new, dedicated page is planned to allow filtering of build template data by vendor, client, and client account number, pulling information directly from the SQL database to show all related service accounts, meters, and line items. Performance optimization for database queries is a noted concern. - The existing UI for viewing per-bill template data is considered valuable for debugging and will be retained, with potential future integration into individual bill details. - **Power BI Reporting and Vendor Management:** Updates were provided on the deployment of a Power BI report and work on a vendor management feature. - A Power BI report named "System Status Bills" has been redeployed to the production service, with minor changes pending. - For ticket PS132, a new "BD Enrolled" field has been successfully added to the edit vendor form. The requirement for this setting to be "filterable in various areas" was clarified to mean adding a filter (similar to the existing Active/Inactive filter) on the vendor management page, which has been implemented. Extending this filter to other reports is a potential future step. - **Report Request for Closed Accounts:** A new report was requested to identify client-vendor accounts that have been marked as final or inactive in the legacy data services (DS) system. This is needed to avoid spending processing time on closed accounts, especially with the upcoming closure of a specific client's accounts. - This will likely be created as a separate report to maintain performance, rather than integrating it into an existing one. - The team will verify if the necessary "inactive" timestamp data is already being stored. ### **Preparation for Critical Client Call** The discussion shifted to preparing for an imminent call with a key client (Yori), where the success of a significant pending deal is at stake. - **Presentation Strategy and Objectives:** The goal of the call is to instill confidence and facilitate the signing of a major deal before year-end. The presentation will cover recent work for three specific clients: Hexpo, St. Elizabeth, and Munson. - The update will be presented directly by the project lead, who is closest to the technical details. - The narrative will focus on issues identified, short-term fixes applied, and the long-term solutions being implemented. - **Client-Specific Data Correction Status:** Progress on correcting data issues for the clients in question was reviewed. - **Hexpo:** A comprehensive overhaul of all accounts has been completed. - **St. Elizabeth:** Data corrections are nearly complete, pending resolution for one account with missing historical data. - **Munson:** A review based on previously identified issues will be finished imminently. - The next planned step is to perform the same comprehensive "sweep" exercise done for Hexpo on St. Elizabeth and Munson accounts, though this is scheduled for after the holidays. - **Communication on System Validations:** A key point of discussion was how to communicate the state of system data validations. - It was confirmed that while some validations had been relaxed in the past to process bills faster, this had not been explicitly communicated to the client. - The strategy for the call is to state that new validations are being *added* to improve data quality, which aligns with the client's stated preference for correctness over speed. This is seen as a way to build confidence without delving into past changes. - **Outstanding Client Requests and Quick Wins:** Several other client requests were highlighted as potential topics or opportunities. - **Bill Health Report:** An investigation is needed into why certain accounts missing usage data are incorrectly showing a "green" healthy status instead of "orange." This is expected to be a point of discussion. - **Multi-Vendor Selection:** A long-standing request for a toggle or multi-select dropdown to assign multiple vendors or commodities to a single bill was discussed. While not a current priority, if it is a relatively simple fix, implementing it could serve as a valuable "quick win" to demonstrate responsiveness. - **Future Onboarding Process:** There was consensus on the need to review and improve the onboarding process for new customers to prevent recurring data issues, emphasizing better upfront organization and setting realistic expectations about data manipulation within the system.

## **Summary** The meeting focused on a critical examination of the data processing pipeline, specifically regarding how bills are matched to existing "build templates" and client accounts. A significant concern was raised about the potential systemic creation of duplicate accounts due to mismatches in the current logic, which could lead to data integrity issues and the propagation of incorrect bill data. The discussion revolved around understanding the current matching algorithm, identifying existing problems, and outlining steps for analysis and remediation. ### **Core Problem: Potential for Duplicate Accounts and Unused Build Templates** The primary issue identified is that the system may be failing to correctly match incoming bills to existing virtual accounts and their associated build templates. This failure could cause the system to create new accounts unnecessarily. - **The Risk of Skipping Build Templates**: When a bill doesn't match an existing account, it bypasses the crucial "build template." This template contains essential safeguards and correct metadata (like unit of measure and observation type). Without it, the system infers this data, which can be incorrect and then propagate to all future bills for that erroneously created account. - **Consequence: Data Duplication and Corruption**: The unchecked creation of new accounts likely means there are numerous duplicate accounts in the database that need to be identified and merged. This undermines data consistency and reporting accuracy. ### **Deep Dive into the Current Account Matching Logic** The conversation drilled into the technical specifics of how the system currently attempts to match an incoming bill's account number to a record in the database. - **Matching Key: Vendor ID and Account Number**: The fundamental matching logic uses the combination of the vendor ID and the account number from the bill to find a corresponding client account. - **Discovery of Data Normalization**: It was revealed that the system already stores a normalized version of the account number (in an `account_number_raw` column), where spaces and dashes are removed. However, the initial understanding was that the matching logic used the original, non-normalized `account_number` field. - **Clarification on Matching Process**: A key clarification was made: the system currently matches based on the original `account_number` column, not the cleaned `account_number_raw`. This means variations in formatting (like added dashes or spaces) would prevent a match, directly contributing to the duplicate account problem. ### **Analysis and Investigation Steps** To understand the full scope of the problem, several immediate investigative actions were proposed. - **Data Export for Analysis**: A request was made to export the full list of client accounts (approximately 27,000 records, excluding inactive ones) for external analysis. The goal is to manually or programmatically search for potential duplicates. - **Audit for DSS-Created Accounts**: A critical task is to determine if the system currently flags which accounts were created by the DSS pipeline itself. If such a flag doesn't exist, it becomes difficult to audit the scale of the issue. - **Implementing Fuzzy Matching**: To identify "near duplicate" accounts that differ slightly due to typos or formatting, the application of fuzzy logic matching techniques on the account number data was suggested as a necessary next step. ### **Proposed Solutions and System Changes** The discussion concluded with actionable proposals to stop the problem from worsening and to fix the existing data. - **Halt Automatic Account Creation**: The most urgent change proposed is to stop the system from automatically creating new accounts when a match isn't found. Instead, such cases should be routed to a manual review process by an operator to prevent further database clutter. - **Implement Creation Tracking**: A system must be put in place to track and flag every new account created by the DSS process. This is a prerequisite for any cleanup operation. - **Review and Revise Matching Logic**: There is a need to re-evaluate the matching logic. The use of the normalized `account_number_raw` field for matching was debated as a way to be more tolerant of formatting differences and reduce false mismatches. - **Future Feature: Template Association View**: A longer-term idea was floated to create a feature allowing users to view all historical bills that have been successfully matched to and processed using a specific build template, enhancing transparency.

## **Customer** The customer is a company leveraging the platform for utility bill management and energy data analytics, specifically for multiple commercial clients in the energy sector. Their role involves overseeing the accuracy and completeness of utility bill data (including electricity, propane, and other commodities) for reporting and operational decisions. The background indicates they are a sophisticated user dealing with complex data ingestion, validation, and reporting workflows, with a focus on ensuring data integrity across historical records and future bill processing. ## **Success** The most significant success has been the proactive identification and systematic remediation of critical data quality issues that were impacting reporting accuracy. A comprehensive review of historical data for key clients has been completed, addressing major problems such as double-counted usage and missing bills. This effort has resolved a substantial portion of the inaccuracies, bringing historical data to a state estimated to be 80-90% reliable for consumption reporting. Furthermore, the process has successfully pinpointed root causes, such as human entry errors and account setup problems, enabling the team to move beyond firefighting and toward implementing preventative, long-term solutions. ## **Challenge** The primary ongoing challenge is related to systematic data ingestion and setup errors, particularly for non-metered commodities like propane deliveries. A core issue is the platform's inability to correctly handle "service dates" for delivered commodities (e.g., propane cylinders), leading to misallocated usage across monthly reporting periods. This stems from the underlying data model assuming all usage is metered. Additionally, ensuring complete bill capture requires correct credential setup for each utility, an operational process that has gaps. The unreliability of automated "bill health" reports creates a lack of trust, as users cannot distinguish between real problems and false positives/negatives. Finally, the reliance on a legacy data system (DDS) that is ill-suited for current workflows complicates the implementation of robust, validated data templates. ## **Goals** The customer's goals, as reflected in the discussion, are multi-faceted: - **Achieve 100% Data Accuracy:** The ultimate aim is to have completely reliable historical and ongoing data for all clients, eliminating errors in consumption reporting and bill-level details. - **Implement Preventative Safeguards:** A key goal is to operationalize "bill templates" to enforce consistent data structure during ingestion, thereby preventing setup errors, double-counting, and mapping issues at the source. - **Establish Transparent Processes:** They seek clear, trustworthy validation and monitoring processes, such as a reliable bill health report, to independently verify data quality without constant manual intervention. - **Transition to Robust Systems:** There is a goal to migrate critical validation logic away from the problematic legacy system (DDS) to a more suitable environment (e.g., DSS or UBM) to support sustainable, accurate data pipelines. - **Ensure Continuous Improvement:** The intent is to move from reactive fixes to a proactive model where insights from data issues directly inform product and process improvements to prevent recurrence.

## Summary The meeting centered on addressing critical data quality and operational challenges within the platform, primarily stemming from gaps in the customer onboarding and bill setup processes. The discussion evolved into planning for system improvements and prioritizing a roadmap for the upcoming year. ### Onboarding Process and Data Source Gaps A core issue identified was the disconnect between customer expectations set during onboarding and the data that ultimately appears in the UBM platform. Currently, onboarding definitions (e.g., locations, vendors, utility types) are managed by CSMs and Data Services (DS) but are not systematically enforced or visible within UBM. This creates a "black box" where discrepancies between what a customer agreed to and what they see are difficult to diagnose. - **Lack of Systematic Validation:** The UBM team ingests bills from Data Services (DS) and Data Services System (DSS) assuming the data is clean and correctly attributed. There is no mechanism to validate incoming bills against the original onboarding template or agreement. - **Difficulty in Root Cause Analysis:** When data issues arise (e.g., double-counting, missing bills), it is extremely challenging to determine if the error originated with the customer's provided information, the CSM/DS handoff, DSS processing, or UBM ingestion. This leads to lengthy manual investigations. - **Proposed Solution Direction:** The conversation explored creating a "source of truth" for onboarding agreements, potentially within UBM's UI or linked from HubSpot. This would memorialize the expected data structure (location, vendor, utility type, service type) so any deviation in incoming bills could be automatically flagged for review. ### Bill Setup, Validation, and Error Management The team delved into the technical intricacies of bill validation, particularly concerning observation types (e.g., generation, demand) and how they are assigned based on utility type and service (distribution vs. supply). - **Historical Data Complications:** A specific pain point is translating historical bills that contain only a single usage line into the platform's distinct distribution and supply virtual accounts. A default rule (assigning to distribution) has been used, but this can cause reporting discrepancies. - **Reinventing Business Logic:** A concern was raised about the risk of duplicating the complex business logic that already exists in DSS and UBM for determining valid observation types. Any new system for defining expectations would need to carefully leverage or mirror this existing logic to avoid conflicts. - **Error Code Dilemma:** The team debated reactivating data validation error codes for postpaid customers. While this would prevent incorrect bills from being displayed, it would also delay bill visibility. The consensus was to aim for reactivation in Q1 or Q2, but only after implementing stronger guardrails, like the proposed build template enforcement. ### Roadmap Prioritization and Q1 Planning The discussion shifted to prioritizing feature development and operational work for the coming quarters, balancing firefighting with strategic platform improvements. - **Immediate Operational Priority (Item 0):** The highest priority is resolving the foundational data quality and onboarding definition issues discussed, as these are the source of ongoing "weekly fires" with customers. - **Customer-Facing Features:** Items like **Contract Management (Item 3)** are becoming a customer expectation and were prioritized over exploratory work like **Interval Data visualization (Item 2)**. However, any document management feature (contracts, onboarding sheets) should be considered holistically from an architectural standpoint. - **Platform Enhancements:** **Dashboard improvements for Bill Pay customers (Item 8)** and moving the **reporting engine off Google Sheets to a proper Azure API (Item 5)** were confirmed as important near-term goals. - **Q1 Realism:** It was acknowledged that Q1 will be heavily focused on operational issues and ongoing onboardings (e.g., Simon). Realistic feature development for the new roadmap items is expected to begin in earnest in February, March, and April. ### Process and Communication Improvements A key takeaway was the need to improve internal processes for managing requests and issues to reduce chaos and increase efficiency. - **Enforcing a Ticketing System:** A major goal for the next year is to mandate the use of a formal ticketing system for all bug reports and feature requests. This is intended to stop the flow of ambiguous requests via chat and email, which require excessive context-gathering from multiple teams. - **Upcoming Leadership Review:** The team prepared for an upcoming review meeting with leadership, aiming to communicate progress on 2025's challenges (DSS integration, validation issues) and set clear expectations for 2026. The message will include the new, stricter process for submitting and tracking work.

## **Summary** The meeting focused on reviewing the current operational strategy, workload prioritization, and key technical issues within the UBM (Utility Bill Management) platform and its integration with PayClearly. The primary objectives were to assess processing queues for key customers, align on data integrity efforts, and coordinate on urgent system updates and payments. ### **Customer Prioritization and Team Workload** The team reviewed a prioritization list for customer accounts, focusing on those with past-due invoices and significant backlogs. - **Primary Focus:** Contractors Daniel and Bilal are primarily dedicated to **Victra** and **Ascension**, with the goal of cleaning up their entire queue in UBM, which includes invoices with due dates from the past, within the next 10 days, and beyond. - **Secondary and Expanded Focus:** Robert is handling **Sheets** and assisting with several Banyan customers (Artgraph, Aspen, Altus). The prioritization list was recently expanded to include **Big Y**, which Robert is now focused on cleaning up. - **Resource Allocation:** Resources are assigned based on due dates to distribute work evenly. Elizabeth primarily supports Banyan, while Karen handles more critical accounts like Medline, PPT, National Bank, and Park Ohio. A new contractor, Jacqueline, has begun assisting with the workload. ### **Operational Metrics and Reporting** A detailed report was discussed to track processing performance and queue status for prioritized customers. - **Report Structure:** The report shows the total number of accounts, invoices with past due dates, invoices due within 10 days, invoices due beyond 10 days, and the volume processed in the previous week. A **month-to-date processed invoices** metric will be added for better tracking. - **Data Discrepancy Resolution:** A discrepancy was noted between the number of accounts shown in the report versus other systems (e.g., 2700 vs. 3180). The team emphasized the need for consistent numbers across all reports and systems, prompting a cleanup initiative for closed accounts that may be skewing the data. - **Efficiency Goal:** The long-term objective is to evolve the UBM operator role into more of an **oversight function**, with an 80/20 rule where 80% of bills process automatically and only 20% require human review for exceptions. ### **Data Integrity and System Issues** Several technical and process-related issues were identified as impediments to smooth operations. - **Account Freezing:** A critical issue was identified where **every account for Ascension was frozen** due to a rules change, halting all processing. This was being actively resolved, with an expectation that accounts would be cleared within 30 minutes. - **Check Cancellation Policy:** The team analyzed the risk of shortening the check cancellation threshold from 21 days to 15 days. Data shows this would increase the risk of canceling a check that would later cash from 1% to **8.1%**, which carries potential repercussions like penalty fees or payment method blocks from utilities. - **Lab & Mock Bill Process:** Updates were made to the "Lab" process and Power BI filters to correctly exclude closed accounts from reports. The process for handling bills where direct system access is unavailable (previously "mock bills") was renamed to **"Expedited Actual Charge" (EAC)**. A co-op is manually retrieving these bills for prioritized customers. ### **Payment Processing and System Updates** Key updates and testing requirements for the payment system integration were highlighted. - **PayClearly File Enhancement:** A two-part update to include 10 additional fields in the UBM billing account and the PayClearly payment file is in the final stages. Although "implemented," it requires **end-to-end business testing** and sending a sample file to PayClearly before deployment. - **Credit Card Payments:** For emergency credit card payments (e.g., for Victra), a solution needs to be operationalized. The action is to discuss with treasury about obtaining a dedicated P-card for such payments and to work with PayClearly on how to handle the associated AP files and fund movement. - **Reporting Cadence:** Mary will take over sending daily processing status updates (starting and ending queue counts) and the weekly IR's report to provide better visibility into workflow. ### **Cross-Functional Coordination** Coordination with the PayClearly team was emphasized to resolve data discrepancies and improve automation. - **Data Discrepancy Investigation:** A meeting was scheduled with PayClearly (Tyler and Amanda) to investigate discrepancies between the payment status data shown in UBM via API versus what is displayed in the PayClearly application itself. The urgency is driven by the need for accurate reporting for clients like Medline and to eliminate manual report pulling. - **API and Real-Time Data:** There is a pressing need to establish a consistent cadence with PayClearly to push for real-time data availability in UBM, which would eliminate significant manual work currently spent on extracting reports from their platform.

## Summary The meeting focused on reviewing ongoing development tasks, clarifying requirements for a new feature, and planning next steps for system improvements. Key discussions revolved around debugging account-related errors, recent UI enhancements, and the strategic rollout of a new system module for managing invoice templates. ### Status Updates and Immediate Priorities The session began with a round of status updates to align on current work and urgent issues. The primary technical concern identified was the need to investigate account-related errors within the system. These errors lack a proper logging mechanism, making them difficult to trace through conventional logs. The team recognized that resolving this issue will likely necessitate significant changes to the underlying processes. Additionally, there was a follow-up on providing example invoices from Hexpull to aid in debugging, with a plan to collaborate on this task later in the day. ### Development Progress on UI and Reporting A significant update was provided on the completion of a front-end enhancement. The work on ticket DS131 successfully added a date picker component to date fields within the file details page. This feature now allows users to either select a date from the picker or type it manually, improving usability. The changes have been deployed to a development test server and are functioning correctly. In parallel, work was done to optimize the database query for the "builds only" report. This optimization is complete and currently undergoing testing in the development environment before being applied to the production database. ### Strategic Implementation of Bill Templates Feature The core of the meeting centered on planning the introduction of a **Bill Templates** management module within the DSS (Data Support System). The goal is to create a dedicated, read-only page where users can view configured invoice templates for different clients and vendors. The discussion clarified that this should be an iterative process, starting with a view-only interface to validate data and workflow before adding edit, add, or delete functionalities. - **Initial Scope and Design:** The feature will reside on a new page in the DSS application, separate from existing modules. The envisioned design includes searchable filters for clients and their associated accounts, as selecting an account is crucial for fetching the correct template data. The displayed information should mirror the structured JSON data found in the production database, showing fields related to commodities, currencies, units, and other vendor-client interrelated data. - **Data Source Clarification:** A key technical point clarified was the distinction between templates used for invoices uploaded via the DSS versus those from other sources (FTG). It was confirmed that when an invoice is uploaded via DSS without an account number, the system cannot fetch the corresponding template structure, highlighting the account number's critical role in the data retrieval logic. - **Future Roadmap:** While the immediate goal is a read-only view, the architecture should be planned with future interactivity in mind. The long-term vision is to allow users to directly edit template fields within this interface and save changes back to the database, transforming it into a comprehensive configuration tool. ### Analysis and Improvement of Account Matching Logic A planned investigation into the system's account matching logic was outlined. The task involves analyzing whether implementing an improved matching algorithm-such as stripping out spaces, dashes, and other extraneous characters from account numbers during comparison-would significantly increase match rates. The expected outcome is a quantitative analysis to understand the potential impact radius: whether this change could resolve a majority (e.g., 80%) of current matching failures or only a minor portion (e.g., 10%). This analysis is crucial for prioritizing development effort and understanding the scale of improvement for data processing workflows. ### Clarifications and Next Steps for the Week The meeting concluded with clear directives for the upcoming work period. The developer assigned to the Bill Templates feature will proceed with implementing the read-only view page based on the clarified requirements. The team also reaffirmed the need to verify the displayed template data with system operators to ensure completeness and accuracy, acknowledging that the initial release might not contain every possible data field. All other discussed action items, including the account error investigation and the matching logic analysis, were confirmed for immediate follow-up.

## Summary The meeting focused on resolving data inconsistencies within the billing and payment systems, specifically addressing ongoing bill error corrections, investigating a critical payment date discrepancy reported by a key customer (Medline), and confirming the resolution of a separate Power BI reporting issue. ### Bill Error Corrections and Process Refinement The discussion centered on addressing and refining the process for correcting bill errors flagged by the quality assurance team. A significant number of bills with past-due amount and unit of measure issues were identified, with a plan to reduce repetitive work by improving the query logic used to generate error reports. - **Addressing Error Reports:** The team reviewed the volume of bills with specific errors, such as "past due amount" and "2015-2016" issues. It was noted that many bills appear across multiple files, leading to duplication in the correction process. A key action is to refine the underlying queries to avoid sending the same bills for review repeatedly. - **Handling Inactive Customer Data:** A specific case involved approximately 50 bills from a deactivated customer (Renu). The decision was made to keep the customer record active for now but to ensure all automated payment processes (AP/bill pay) are switched off to prevent any unintended downstream financial transactions. - **Next Steps for Error Resolution:** The immediate plan is to send the updated files containing the current batch of errors (roughly 75 bills after exclusions) for processing. A follow-up call with the quality assurance analyst (Mary) was suggested to collaboratively refine the query filters and improve the efficiency of the error identification workflow. ### Investigation into Payment Date Discrepancy A substantial portion of the meeting was dedicated to investigating a critical discrepancy in payment dates between the internal platform (UBM) and the payment processor's (PayClearly) data, which was raised by the customer Medline. The team conducted a detailed forensic analysis to pinpoint the source of the inconsistency. - **Identifying the Problem:** The customer reported seeing different "cleared" dates for the same payment across two sources: the UBM platform and a detailed report from PayClearly. For example, one payment showed as cleared on December 11th in UBM but on December 10th in the PayClearly detail report. - **Forensic Data Analysis:** The team examined various data sources, including the UBM payment status tab, generated AP/PC files, and the PayClearly API data within Power BI reports. The goal was to trace the origin of each date field (e.g., file creation date, sent date, cleared date) and understand how they are stored and displayed (UTC vs. local time conversion). - **Pinpointing the Source of the Discrepancy:** The investigation concluded that the data shown in UBM is pulled from the PayClearly API. The discrepancy arises because PayClearly provides **two different data streams**: a real-time, detailed internal report and a slightly delayed API feed. The "cleared date" shown in the detailed report appears to differ from what is provided via the API, likely due to definitions of "cleared" or timing differences in ACH settlement. - **Resolution Path:** Since the root cause lies within PayClearly's systems and data definitions, the team agreed the issue must be escalated directly to PayClearly. The plan is to initiate a formal inquiry, involving previous points of contact (Tim, Tyler), to ask why their two data sources provide conflicting information for the same transaction. ### Power BI Report Status Verification The meeting briefly reviewed the status of a Power BI report concerning virtual account statuses, confirming that a previously identified issue had been resolved. - **Confirming Logic and Functionality:** The report's logic, which determines an account's status based on its associated virtual accounts, was reconfirmed. The rule states that if any virtual account is "open" or "unknown," the overall account status is "open"; it is only "closed" if all linked virtual accounts are closed. - **Issue Resolution:** A previous concern that this logic had stopped working was addressed. It was confirmed through recent communication that the report is now functioning correctly and displaying account statuses as defined by the agreed-upon business rules. ### Closing and Forward Actions The meeting concluded with an agreement on the immediate next steps, primarily focusing on external communication to resolve the core payment discrepancy issue. - **Primary Action:** The main forward action is to formally escalate the payment date discrepancy to the payment processor, PayClearly. This will involve starting a communication thread to seek clarification on why their API data differs from their detailed report data, ensuring all relevant internal stakeholders are included in the conversation for transparency. - **Ongoing Monitoring:** While the Power BI report issue was resolved, the discussion underscored the importance of monitoring such systems after changes are made to ensure business logic remains correctly applied.

## Matching Logic and Workflow Failures The meeting focused on diagnosing critical failures in an automated billing processing workflow, specifically within a system referred to as DSS (Data Services). The core problem is a rigid, hierarchical matching logic that causes bills to fail processing or create erroneous new accounts when data doesn't perfectly align with predefined templates. The discussion revealed that the process begins by attempting to match incoming bill data (account number and vendor ID) against a database. If this initial match fails, the entire workflow halts, sending the bill to a "failure state" where it remains stuck in "DSS in progress" without any notification or rollback to a prior system (DDS). This creates a silent backlog of unresolved bills. Conversely, if a match is found, the system proceeds to fetch associated account templates, service accounts, and meter data. However, failures at any subsequent level (e.g., missing service accounts) cause the system to skip critical validation steps, leading to incomplete or incorrect bill processing. ## Issues with the Hierarchical Data Model A significant portion of the conversation dissected the complex and fragile data hierarchy used for matching. The process requires perfect matches across multiple sequential layers: Client Account -> Service Account -> Meters -> Line Items. This structure is problematic because: - **It assumes data perfection:** The logic expects immutable data fields like `build class` (e.g., full service vs. supply) and `service address` to be consistent and correctly inferred from every bill, which is rarely the case in practice. - **It creates single points of failure:** If an account number has a formatting discrepancy (like a missing dash or space), all downstream steps, including commodity type and rate code identification, are skipped or fail. - **It relies on unreliable data:** Key matching fields for line items, such as `caption`, `commodity item description`, and `unit description`, are often parsed inaccurately by other systems (implied to be an LLM), making consistent matches unlikely. ## Proposing a Fundamental Rethink of the Process The consensus was that the current "all-or-nothing" matching approach is unsustainable. The group advocated for a paradigm shift with two key principles: - **Eliminate auto-creation during ingestion:** The system should never automatically create new accounts or templates during bill processing. This practice has led to a proliferation of unvetted data and makes problem diagnosis extremely difficult. - **Embrace "fail fast and flag" over "guess and proceed":** It is preferable for the system to clearly fail a bill when a confident match isn't found and flag it for human review, rather than attempting to proceed with incomplete or guessed data, which results in hidden errors. The proposed solution involves implementing **fuzzy matching logic**, particularly for account numbers, to handle common variances like spaces, dashes, and leading zeros. This is identified as the single most impactful fix that could resolve a majority of matching failures. ## Analysis and Investigation Plan To move forward, the team outlined a data-driven investigation plan: - **Conduct a fuzzy logic analysis:** The first action is to query all historical account number matching failures, apply fuzzy logic (stripping special characters, spaces, etc.), and quantify how many would have been resolved. This will validate the potential impact of the proposed fix. - **Perform end-to-end data mapping:** There is a need to create concrete examples that map data from the source bills, through the database templates, to the UI. This will ground future discussions in real data and clarify the current system's behavior. - **Audit template origins and change management:** Questions were raised about who can create or edit templates and in which systems (e.g., a legacy system vs. UBM). A related issue is the lack of version control for templates, making it impossible to apply changes retroactively or understand the historical context of a bill's processing. ## Addressing Downstream Implications and System Trust The flaws in the matching logic have eroded trust in the entire billing data pipeline. The team connected these ingestion problems to downstream reporting issues, such as **observation mismatches and double counting** in analytics. Furthermore, the inability to reliably match bills means many are not linked to any client account in the system, rendering them invisible for management and reporting. A long-term vision discussed includes introducing **versioning for build templates**, allowing for controlled changes that apply only to future bills and providing an audit trail. The immediate goal, however, is to stabilize the ingestion process by relaxing overly strict matching rules and replacing them with more robust and transparent validation.

## Summary The meeting centered on reviewing critical data quality and billing issues affecting three key customers: Hexpoal, Munson, and St. Elizabeth. The primary goal was to understand the scope of problems, align on root causes, and prepare a unified strategy for addressing them with the client in an upcoming meeting. ### Overview of Customer-Specific Cleanup Efforts A deep dive was taken into the cleanup work already performed for St. Elizabeth and Munson to identify patterns and recurring problems. The cleanup process involved a systematic sweep of customer accounts. This started by comparing account lists against a **Bill Health Report** to identify missing bills or erroneous data. The major issues uncovered fell into several categories: missing bills due to incorrect retrieval methods or unprocessed invoices, incorrect service dates (particularly for deliverable commodities like propane), missing or duplicate consumption lines, and account setup errors (e.g., distribution vs. full service). ### Root Cause Analysis of Identified Issues The discussion moved to diagnosing the underlying reasons for the persistent data problems, which are largely systemic. For **missing bills**, the cause is often a mismatch between expected and actual retrieval methods (e.g., web download vs. email), or bills being deprioritized and stuck in processing queues. **Incorrect service dates** are a fundamental challenge for delivered commodities (like propane or refuse), where the billing system must infer dates rather than receiving explicit service period data, leading to gaps that skew reporting. Many other errors stem from **incorrect initial account setup** that then cascades, causing ongoing data discrepancies. ### The Challenge of the Bill Health Report Reliance on the primary diagnostic tool, the Bill Health Report, was scrutinized due to its high rate of false positives and missed issues. While used as a starting point, the report is often misleading. It generates false positives for accounts with non-monthly billing cycles (like quarterly), closed accounts that haven't been updated in the system, and accounts with incorrectly configured service types. Consequently, the client has lost trust in this report, necessitating a new, more reliable process for identifying truly missing or erroneous data. ### Strategic Preparation for the Client Meeting The conversation focused on formulating a transparent and defensible position for the imminent meeting with the client, Jennifer. A key objective is to categorize all known issues into three clear buckets: systematic fixes needed from the development team, one-time cleanup tasks, and items requiring the client's own assistance. The strategy is to demonstrate that no new, unknown issues have been discovered with Hexpoal, Munson, and St. Elizabeth-only existing, understood problems. A major point of discussion was how to handle requests for **historical data cleanup**. The approach will be to carefully define what portion of historical errors are attributable to past processes versus current operations, as committing to a full, rapid historical cleanup may be unfeasible. ### Long-Term Solutions and Process Gaps The discussion concluded by acknowledging the need for enduring solutions beyond immediate cleanup. There is a clear need to **rethink how delivered commodities are handled** within the system to prevent ongoing date inaccuracies. Furthermore, there is a critical gap in **validation and error flagging**; some validations were muted in the past, allowing errors to slip through. Re-enabling and improving these automated checks is essential for preventing future issues and efficiently identifying existing ones, rather than relying on manual account-by-account review.

## Summary The meeting focused on resolving authentication and access issues related to SendGrid and its integration with Power BI for reporting and invoicing purposes. A significant portion of the discussion involved troubleshooting two-factor authentication (2FA) problems and establishing proper user access across different environments. ### Troubleshooting SendGrid Authentication Issues The primary challenge was gaining access to the SendGrid production account, which was protected by an unexpected two-factor authentication setup. The process was hindered because the authentication code was not being received via text message as expected. This blockage prevented access to crucial data needed for tasks like invoicing. - **Unexpected 2FA Block:** The account required a code from an Authenticator app, but it was unclear who had initially configured this security measure. Attempts to bypass it by requesting a code via SMS failed, as the expected text message was not delivered. - **Security Policy Complications:** The discussion acknowledged that while security teams (like Cyber) are essential, their protocols can sometimes create obstacles for operational tasks, creating a tension between security compliance and the need to perform job functions efficiently. ### Account Access and Permission Management A solution was engineered by directly managing user invitations and permissions within the SendGrid platform itself, sidestepping the problematic 2FA on the service account. - **Direct User Invitation:** Access was granted by sending direct invitations to a user's corporate email address for all three SendGrid environments: Development, Demo, and Production. - **Clarifying Account Types:** A distinction was made between user accounts (for human access to the dashboard) and service accounts or API keys (used for system integrations). The problematic 2FA was linked to a service account, not a standard user login. - **Permission Cleanup:** It was noted that duplicate entries for service accounts existed within the shared password manager (1Password), indicating a need for future cleanup to maintain credential hygiene. ### Security and Infrastructure Constraints The conversation highlighted broader organizational challenges related to security tools and development environments. - **Power BI Access Hurdles:** Internal security layers had recently been enhanced, which inadvertently blocked Power BI from accessing necessary data sources. This required additional work with other teams to re-establish connections for reporting. - **Platform Limitations:** The inability to run Power BI desktop on a Mac operating system posed a personal challenge for one participant, who explored using a remote virtual machine as a workaround. This investigative action itself triggered an alert from the cybersecurity team. ### Transition from SendGrid to Twilio Authentication An underlying cause for some login confusion was identified as an ongoing migration of authentication systems. - **Platform Migration:** Evidence suggested that authentication for the production environment was in the process of being transitioned from SendGrid's native system to Twilio's platform, which could explain irregular login behaviors and interface discrepancies. - **Billing Discrepancy:** During login attempts, an odd outstanding balance was observed on an invoice that did not align with the main billing records, though this was not resolved during the meeting. ### Resolution and Access Confirmation The meeting concluded successfully with access being restored through the alternative method of direct user account provisioning. - **Successful Provisioning:** The participant confirmed receipt of invites and successfully set up access to the Development environment, with instructions to repeat the process for Demo and Production. - **Achieved Outcome:** The core objective of gaining administrative access to SendGrid for operational management was achieved, moving past the initial authentication deadlock. This access will enable future management of settings, stats, consumption data, and invoicing.

## Summary The meeting was a technical deep dive into the current implementation and issues surrounding the "build template" process. The core problem is that while the system is designed to use predefined templates from a legacy database to ensure data consistency in the UBM (Utility Bill Management) system, malfunctions in this process are causing significant data integrity issues for clients. The discussion aimed to diagnose why the template logic isn't working as intended and to plan a path forward for both immediate client communication and a long-term, reliable solution. ### Understanding the Build Template's Purpose and Current Flow The build template is intended to act as a source of truth, pulling predefined customer setup data (like vendor, account number, commodity type) from a legacy system to populate and validate bills processed in the DSS. Its primary function is currently to populate the legacy system's database for operator review, but its potential for enforcing data integrity is not fully leveraged. - **Current Process Flow:** The template logic is executed after initial processing (IPS) and priority checks in the DSS. - **Data Transformation:** Data from the PDF extraction is first converted into a structured invoice format, though key fields like account ID may be null at this stage. - **Template Fetching:** The system attempts to fetch the correct template from the legacy database using the extracted **vendor ID and account number** as the primary matching keys. - **Goal of the Process:** Proper implementation should resolve common issues like double-counting consumption and mislabeled bill types by ensuring all incoming bills conform to a predefined, correct setup. ### Diagnosing the Critical Failure in Matching Logic A central discovery was that the template matching logic is **hierarchical and sequential**, where a failure at the first matching step causes the entire process to fail, leaving the system to infer all data without the template's guidance. - **Hierarchical Matching Cascade:** The system performs matches in a strict sequence: first by account number and vendor, then by service account, meter, and line data. If the initial account+vendor match fails, subsequent steps are not executed. - **Root Cause of Issues:** Many errors stem from this first match failing. A discrepancy between the account number on the PDF and the one stored in the legacy system template is enough to break the chain. - **Consequence of Failure:** When no template match is found, the DSS is left to infer all field values on its own, leading to the very data inconsistencies the template was meant to prevent. ### Identified Systemic Issues and Limitations Beyond the matching logic, several systemic and operational constraints exacerbate the problem, making fixes and historical data cleanup challenging. - **Inability to Edit Templates:** A major limitation is that once a template entry (e.g., an incorrect unit of measure) is added to the legacy system-whether manually or by DSS inference-it cannot be removed, only supplemented. This pollutes the source of truth. - **Lack of Visibility and Control:** Operations teams in UBM currently have no visibility into what the predefined template settings are. Their manual corrections are made in a vacuum, potentially creating new, inconsistent "versions" of the truth without updating the core template. - **Manual Historical Data:** A significant portion of the problematic historical bill data was processed manually, creating a baseline of inconsistencies that the automated system must now contend with. ### Implications for Client Reporting and Strategic Decisions The technical problems directly impact how to communicate with a concerned client (Hexpol/ULA) and what strategic remedy to propose for their and other clients' data. - **Communicating Realistic Solutions:** There is a strong emphasis on being transparent with the client about what can and cannot be fixed, distinguishing between solving issues for future bills versus remediating historical data. - **The Re-ingestion Question:** A strategic debate emerged on whether to perform a comprehensive "re-ingestion" or "re-scrubbing" of a client's historical bills once the root causes are fixed. This would treat the corrected data as a new onboarding, potentially reducing long-term manual review but setting a precedent other clients may request. - **Defining a "Golden Record":** A proposed solution involves creating a definitive, agreed-upon artifact (e.g., a comprehensive spreadsheet) that maps every unique combination of site, vendor, commodity, and account to a single, correct setup. This would serve as an immutable reference for both the AI and client agreement moving forward. ### Proposed Next Steps and Investigation Path The meeting concluded with a clear action plan to further diagnose the exact failure modes and to prepare for client communications. - **Deep-Dive Technical Documentation:** A follow-up was scheduled to document the exact step-by-step matching logic with concrete examples, clarifying what data is used and what happens upon match success or failure at each stage. - **Data Analysis for Client Discussion:** The team will pull the existing build template data for the Hexpol client to visualize the current "state of the truth" and assess how much of the data problem would be resolved by fixing the matching cascade. - **Redefining the Template's Role:** A key future goal is to evolve the build template from a simple population tool into an active **data integrity layer** that validates and corrects DSS output before it reaches the legacy system or UBM. - **Internal Strategy Alignment:** Before the client meeting, an internal sync is needed to align on messaging, deciding what fixes are promised for the future and what, if any, plan is proposed for historical data remediation.

## **Summary** ### **Upcoming Planning Sessions and Strategic Alignment** The meeting primarily focused on coordinating upcoming strategic planning sessions and aligning the team's roadmap for the upcoming quarters. The core objective is to establish a coherent plan for Q1 and the first half of 2026, with an emphasis on operational stability over new feature development. - **European Planning and Q1/H1 Roadmapping:** Discussions are centered around finalizing plans for the European market and the broader Q1/H1 2026 strategy. Multiple dedicated sessions are already scheduled throughout the week to work through these plans collaboratively. - **Operational Focus for Early 2026:** The anticipated roadmap for at least the first half of the coming year is expected to be heavily focused on resolving existing operational issues and removing blocking dependencies, rather than on fulfilling new feature requests. The goal is to solidify the foundation of the operational product. - **Preparation for Leadership Review:** A meeting set for Friday by a colleague (Gary) was discussed, framed as a "2025 review and 2026 planning" session. The expectation is that the outcomes from the team's internal planning sessions will be synthesized into a shareable format, such as key bullet points, to present for alignment and feedback from leadership. ### **Coordination and Scheduling of Key Meetings** Significant time was dedicated to aligning calendars and ensuring efficient preparation for the critical planning discussions. - **Internal Team Sync:** A specific internal sync was scheduled for Thursday to consolidate the team's position and finalize materials ahead of the broader review meeting. The timing was carefully coordinated around existing commitments. - **Integration with Ongoing Sessions:** There was a strong intention to leverage the existing planning meetings happening earlier in the week (Wednesday) to draft the initial materials, making the subsequent Thursday sync a final locking and review step. ### **Side Discussion: Research on Behavioral Science in Product Strategy** A separate, more personal topic was introduced regarding academic research into the application of behavioral science within product development. - **Request for Expert Contacts:** One participant is conducting MBA research on how behavioral science insights and nudges can drive product strategy and innovation, particularly focusing on the gap between user motivation and stated intentions. - **Networking Assistance:** The other participant agreed to search their professional network for potential contacts with relevant experience, whether from internal corporate roles (e.g., data scientists or behavioral science groups) or from a design thinking perspective that intersects with behavioral insights. The goal is to facilitate introductory conversations to gain real-world insights for the research project.

## **New Weekly Reporting Structure and Customer Oversight** A new standardized weekly reporting process has been implemented to provide comprehensive oversight of all customer accounts. This initiative involves both the download and operational sides of the business using a shared customer list template. The primary goal is to create a single source of truth for account status, proactively answer leadership questions, and eliminate frustration caused by data mismatches or missing information. The reports are intended to be high-level summaries rather than raw data dumps, providing leadership with actionable insights without needing to sift through numerous detailed documents. - **Implementation of a unified template:** A standardized template has been distributed and must be filled out weekly by the team. This is designed to wrap operational arms around all customers from initial download through final processing. - **Addressing account vs. meter data:** A key focus is reconciling the number of *accounts* versus *meters*, as invoices are processed by account. Initial discrepancies in the data are anticipated and will require investigation to align both teams on the true operational scope. - **Structured meeting schedule:** These reports will be reviewed in dedicated weekly one-hour meetings. The schedule is being adjusted, with plans to move to a regular Tuesday slot. ## **Customer Escalation: Aurora University Billing Data Dispute** A significant escalation occurred with Aurora University, centering on a dispute over the granularity of billing data accessible to the customer. The situation is complex due to conflicting internal and external communications about the core issue. ### **Conflicting Perceptions of the Problem** The customer's complaint, which escalated to senior leadership, framed the issue as an inability to extract usage data by meter from their invoices. Internally, however, the understanding is that the customer is requesting highly customized data widgets and analytics at the meter level, which would require new development work. - **Escalation to leadership:** The issue "blew up" via email, reaching high-level executives and creating urgency. Internal confusion persisted because the customer's stated problem did not match the team's understanding of the actual request. - **Potential root cause:** There is a strong suspicion that a sales or onboarding promise was made to the customer regarding data accessibility that the current system cannot fulfill without technical modifications. - **Next steps:** A meeting with the customer is being arranged for the following week to clarify their exact requirements, involve the development team to assess feasibility and potential cost, and determine a path forward. ## **System Functionality and Operational Checks** Concerns were raised about the stability and intended function of certain system safeguards, specifically within the billing extension process. A flag designed to halt invoices over $24,000 for customer approval was questioned, prompting a verification of its operational status. - **Verification of a critical control:** It was confirmed that the system flag for high-value invoices is still active and functioning, alleviating concerns that it had been accidentally disabled or removed. The inquiry appears to have stemmed from a one-off manual override or processing exception. - **Ongoing manual reporting:** Leadership has requested operator metrics from the UBM (Utility Bill Management) system. This report on individual operator clearance volumes is currently a manual process managed by a specific team member and has not yet been automated. ## **Holiday Schedule and Team Coverage** Coordination for the upcoming holiday period was discussed, with a focus on ensuring business continuity and managing customer expectations during days with reduced staffing. - **Overlapping time off:** Key team members have scheduled days off around Christmas Eve and Christmas Day. Plans are being made to ensure coverage for critical tasks, with an emphasis on processing all invoices before the holiday to avoid disconnection risks. - **"Scream-free" policy:** A clear boundary was set for the holiday period: while team members may be online for processing work, they will not be attending meetings or responding to emails where customer "screaming" or high-intensity complaints are expected. The goal is to enforce a peaceful operational window. - **Awareness of external closures:** It was noted that many clients and utility providers may also be shut down during this period, which will naturally reduce the volume of commodity pricing updates and related work. ## **Pending Actions and Upcoming Discussions** Several items were flagged for immediate follow-up and coordination in the coming days, indicating a busy operational pipeline. - **Data report consolidation:** A combined report from Data Services and UBM is being shared to serve as a potential single source of truth, though its data still requires full verification from all operational angles. - **Urgent customer meeting scheduling:** Efforts are underway to schedule a meeting with the Aurora University customer for Wednesday or Friday of the current week. The preference is to resolve the issue quickly and avoid letting it linger. - **Team resource planning:** The departure of a contractor has forced a reassessment of hiring needs. Discussions will determine whether to shift an existing team member and hire for their previous role or to hire directly for the vacant position. - **Financial oversight gaps:** An admission was made that billing for carbon accounting services has likely lapsed due to bandwidth constraints, potentially representing lost revenue. This area requires immediate attention to rectify.

## Summary The meeting focused on progressing development work across several key areas, primarily involving data integrations, user interface features, and code deployment processes. The team reviewed current ticket statuses, discussed the implementation of a new build template management feature, and addressed ongoing efforts to streamline the integration between systems. ### Report Status and Next Steps A primary report is nearing completion, with only minor pending changes anticipated. The team is preparing to finalize this deliverable, acknowledging that some feedback for improvements may still be received from stakeholders. - **Finalizing a key report:** The report is largely ready, with plans to submit it after incorporating a few final adjustments. This step is crucial for closing out a significant project milestone. ### Technical Integrations and Ticket Updates Significant discussion centered on technical tasks related to data flow and system functionality. A Python script for converting XML to the DSS format was reviewed, marking progress on a core integration piece. Several specific tickets were addressed concerning data validation and invoice processing. - **XML to DSS Mapping Progress:** A developer has shared a Python script and mapping documentation for converting data from XML to the DSS and HJS formats. This foundational work for data interoperability will be examined in detail to inform the next implementation steps. - **Resolving Invoice and Data Validation Issues:** Issues preventing invoices from being sent to DSS were investigated and resolved, with code fixes deployed to test environments. Additionally, a fix was implemented and pushed for a data validation problem related to build status filters in DSS, ensuring all filtering options work correctly for users. - **Tracking User Actions for Invoices:** Development was completed on a feature to track users when they upload invoices directly to TSS. While functional in development, a display issue with user columns in the test environment requires further investigation into the test database. ### Build Template Feature Development A major initiative to surface and eventually allow management of "build templates" within the user interface was planned. The discussion clarified that the data already exists and is used within DSS, so the initial phase focuses on making it visible to operators. - **Phased Implementation Approach:** The feature will be developed in stages, beginning with a read-only view of existing build template data in a new UI page. Subsequent phases will enable users to edit templates and finally create new ones, addressing a critical gap as these templates are currently only manageable in a legacy system. - **Clarifying Requirements and Data Source:** To proceed, developers will analyze the existing DSS API, specifically the import and build template processes, to understand how the data is currently populated and structured. This will inform the design of the new interface. ### Code Deployment and Process Improvements The team identified a need to improve the merging and deployment workflow to prevent environment synchronization issues and reduce manual conflict resolution. - **Merging Open Changes to Production:** A directive was given to merge all pending DSS and FTG changes to the production environment to ensure all environments are up-to-date and consistent. - **Establishing a Better Merge Process:** To avoid future conflicts and keep development branches current, a new process was suggested. Developers should regularly rebase their feature branches against the production codebase, especially if a pull request remains open for several days, to minimize integration headaches.

## Summary The meeting focused on investigating and diagnosing a reported data discrepancy between different systems, specifically concerning date and timestamp values in financial or transactional records. ### Initial Problem Statement: Data Discrepancy in Reports A core issue was identified where data shown in a "UBM Processing Report" does not match the data received from external APIs or seen in other platforms like PayClearly. The discrepancy manifests in date columns, with mismatches observed in fields such as "Loaded on" and "Tracked at" dates. - **Discrepancy Evidence:** The team examined an Excel file provided by the client, which highlighted specific rows where dates and times did not align. For instance, one record showed a "Loaded on" time of "11:27" in one system but "11:26" in another, indicating a difference not solely attributable to simple time zone shifts. - **Core Question:** The primary challenge was determining the exact source of the data in the "UBM Processing Report" and the "PC Details" column to understand why the values differ from the data ingested via API. ### Investigation into Data Sources and Systems A significant portion of the discussion was dedicated to tracing the origin of the conflicting data points to pinpoint where the transformation or error occurs. - **Identifying the "PC Data" Source:** There was uncertainty about where the data in the "PC Details" column originates. It was clarified that while data is received from an external API (the "track API"), there is no known "PC detail report" within the internal UBM system. This suggests the client might be using a separate, unidentified Power BI report or data source. - **Comparing API Data with UI:** Analysis confirmed that the timestamp data received from the external API ("funded at" dates) matches what is displayed within the internal platform's UI, suggesting the ingestion pipeline is intact. - **UBM Report Ambiguity:** The team could not definitively identify what the "UBM Processing Report" referenced in the client's data represents, making it difficult to audit the transformation logic applied to the data in that specific output. ### Analysis of Time Zone Conversion as a Potential Cause The possibility that the discrepancies were caused by automatic time zone conversions was thoroughly explored, as this is a common issue with date-time data across regions. - **Platform Conversion Logic:** It was confirmed that certain pages within the application (like the Bill Summary page) automatically convert UTC timestamps from the database to the viewer's local time zone. This means users in different locations (e.g., the US, Romania, or India) would see different localized dates and times for the same underlying UTC event. - **Excel's Auto-Conversion Risk:** A critical technical point was raised that Microsoft Excel can automatically convert date-time data to the user's local system time zone upon opening a file. This could introduce a discrepancy if the data in the file was stored in UTC but displayed in a local time zone without explicit formatting. - **Assessment of Fit:** While time zone conversion could explain date shifts (e.g., a UTC time rendering as the previous day in a later timezone), it was noted that some observed discrepancies involved differences in minutes (e.g., 11:26 vs. 11:27), which cannot be explained by whole-hour time zone adjustments alone. ### Examining Specific Client Data Points The team drilled down into a specific example from the client's spreadsheet to contextualize the theories. - **Case Study of Bill 1105915:** Using a specific bill ID, it was demonstrated how the "Loaded on" date appears as "11/27" in one location and "11/26" in another, directly illustrating the reported problem. - **Contradiction in Theory:** For the example examined, the "Tracked at" field in the API data (in UNIX/UTC format) should have converted to a "12/11" date. However, the client's data showed "12/10," reinforcing that the issue may not be a straightforward display conversion but rather the use of a different source data point altogether (e.g., a "submitted date" versus a "tracked at" date). ### Conclusions and Required Next Steps The discussion concluded by defining the blockers to resolution and the necessary information to proceed. - **Root Cause Hypothesis:** The leading theory is that the client's "PC Detail Report" uses a different source date field (e.g., a "clearing date" or "submitted date") than the "tracked at" field provided by the API and displayed in the application UI. - **Critical Missing Information:** A resolution cannot be reached without first understanding the exact source and definition of the data presented in the client's "UBM Processing Report" and "PC Details" column. The team needs to know which specific database field or report logic generates those values. - **Recommended Action:** It was agreed that the fastest path forward is to request the client provide screenshots of the specific application pages or report definitions in question. This will allow for a direct comparison between what they see in the system interface and the data in their discrepancy report.

## Customer The customer is a significant client with a complex account structure, managing a large portfolio that requires meticulous oversight of invoicing, billing, and data integrity. Their operations involve high-volume transaction processing and detailed reporting, indicating a mature, data-driven approach to managing their financial and service obligations. They are deeply integrated into the platform, utilizing it for core operational functions and expecting a high degree of reliability and accuracy. ## Success The most significant achievement has been the strategic move toward establishing a single, verified source of truth for all account data. This initiative involves consolidating scattered reports and lists into a master account list, which will serve as the definitive foundation for all future reporting and operations. This centralization is seen as a critical step to eliminate inconsistencies and ensure that all teams are working from the same, accurate dataset, thereby improving overall decision-making and operational efficiency. The proactive effort to clean up duplicate accounts and validate data integrity further underscores progress toward this goal of reliable, unified information. ## Challenge The primary and most persistent challenge revolves around **data quality and system reliability**. A major issue has been the existence of duplicate accounts within the system, which distorts reporting and creates operational overhead for cleanup. This is compounded by technical bugs, notably within the web download helper tool, which have impeded data processing and led to missed or inaccurate invoices. Furthermore, unplanned system outages have directly impacted billing cycles and, critically, the communication flow to the customer regarding these issues. This lack of proactive transparency during downtime has led to frustration and eroded trust, highlighting a gap in crisis management protocols. ## Goals The customer's key objectives are centered on achieving operational excellence and system dependability. Their goals include: - **Data Integrity:** To have a completely clean, accurate, and validated master list of all accounts, free from duplicates and errors, forming a reliable foundation for all processes. - **Process Reliability:** To ensure all invoices are processed correctly and on time, eliminating the need for manual intervention or "mocks" due to system failures or data gaps. - **System Stability:** To experience consistent platform uptime and performance, with robust technical infrastructure that prevents bugs and outages from affecting core workflows. - **Proactive Communication:** To receive timely, transparent communication during any service disruption, allowing them to manage their own downstream processes and expectations effectively. - **Scalable Management:** To seamlessly onboard and manage new, large-volume accounts (like the upcoming replacement for a major client) without a degradation in service quality or an increase in operational friction.

## **Summary** The meeting focused on reviewing the status of ongoing technical projects and bug fixes, with a particular emphasis on data reporting and system integration challenges. Key topics included progress on a new Power BI report for tracking late invoices, resolving discrepancies in invoice data synchronization, and planning a significant enhancement to the DSS system to better manage and display account information. The discussion also touched on upcoming national holidays affecting the team's schedule. ### **Status Updates on Technical Work** The session began with progress reports on several active tickets and development tasks. - **New Power BI Report Development:** Work is ongoing to create a new Power BI report to replace older, complex reporting methods. A critical issue was identified where three specific accounts were not appearing in the new report due to a one-day difference in the logic calculating the "expected date." The report's core function is to flag accounts where the expected invoice date is in the past. A new page is also being added to show *all* accounts for a customer without any date-based filters, aiming to create a single, comprehensive source of truth for account data. - **FDG Connect Bug Fixes:** Several user interface and data flow bugs in the FDG Connect system were addressed. Updates were made to ensure proper vendor selection and pagination reset in task lists. Furthermore, an investigation was conducted into a reported issue where manually entered invoice dates during bill upload were being overwritten by dates extracted by AI during processing in the DSS system. - **DSS User Tracking Feature:** Development is still in progress for a feature that logs which user uploaded an invoice directly through the DSS system. This work is proceeding on a part-time basis. ### **Data Synchronization and Invoice Date Issues** A significant portion of the discussion centered on data integrity issues between the FDG Connect and DSS systems. - The core problem involves a mismatch between invoice dates. When a user manually inputs an invoice date while uploading a bill via FDG Connect, this date is sometimes replaced by the "bill date" extracted from the PDF by an AI automation process when the data is pushed to DSS. - This is perceived as a data overwrite issue, though it was clarified that the originally reported bug might have been related to tasks reappearing in FDG Connect due to failed uploads, not just the date change itself. More information from the operations team was requested to debug this effectively. ### **Strategic Enhancement for DSS Account Management** A major strategic initiative was outlined to solve fundamental data context problems within the DSS (Data and Decision Support) system. - **The Core Problem:** DSS currently lacks a clear view of all pre-existing service accounts for customers, which are stored as "build templates" in the legacy DDIS system. This missing context makes it difficult to verify if all expected bills are being captured. - **Proposed Solution:** A three-pronged approach was agreed upon: 1. **Expose Existing Data:** Create a new page in the DSS UI to display all customer accounts and vendors, pulling data from the existing templates that are already being used post-IPS processing. 2. **Enable Template Management:** Allow users to modify these build templates directly within DSS, establishing them as the definitive source of truth for account setups. 3. **Improve Data Rigidity:** Ensure the system is more careful in creating new templates, as continuous creation indicates a failure to match incoming data to existing setups. The goal is to start development on this critical feature the following Monday. ### **Analysis of Power BI Report Logic** The conversation delved into the specific logic causing discrepancies between the old and new Power BI reports. - The discrepancy for the three missing accounts was traced to a **one-day calculation difference** in the expected date. In the old report, an account with an expected date of December 10th appeared as "late" on December 11th. The new report's logic showed the expected date as December 11th for the same account, so it did not appear as late until December 12th. - The strategic direction shifted towards **building a foundational "account list" view first**. This comprehensive list of all accounts, without any late-payment logic applied, will serve as the primary data source. The "late arriving bills" view will then become a simple filter or slice of this master list, ensuring consistency and accuracy. ### **Operational and Administrative Notes** The meeting concluded with brief administrative coordination. - The team confirmed upcoming company holidays for December 25th and 26th, though there was a need for clarification on whether both days were officially off. - A separate discussion occurred regarding internal tool access, noting that attempts to set up a local virtual machine to run Power BI on a company laptop triggered a security alert from the cybersecurity team, highlighting the locked-down nature of the work environment.

## Customer The customer is an organization using a utility bill management and payment automation platform. Their primary role involves overseeing and managing a high volume of utility bill transactions across multiple locations, vendors, and utility types. The platform is intended to centralize bill processing, data extraction, analysis, and automated payments for their operational portfolio. ## Success The most significant success achieved is the fundamental automation of bill payment processing. Despite facing numerous operational challenges, the platform enables the customer to manage and pay a large volume of utility invoices that would otherwise require an immense manual effort. It facilitates the handling of transactions for numerous accounts and helps in identifying billing data, even amidst complex scenarios involving multiple vendors and utility commodities. The system also supports foundational compliance work, such as preparing for SOC 2 Type II certification, which is a critical requirement for enterprise credibility and risk management. ## Challenge The most prominent and recurring challenge is the unreliability and lack of data integrity within the system, which directly impacts core operations. A primary issue is the frequent misclassification of bill data-where utility consumption units, costs, or vendor details are incorrectly extracted or mapped. This leads to downstream errors in analysis, reporting, and automated payments. Furthermore, there are systemic problems with payment processing, including invoices not being paid on time due to issues with third-party payment partners, which risks service disruptions. The team is also grappling with "bad data" that entered the system historically, requiring significant manual review and cleanup. The lack of a single source of truth or a rigid "bill template" for each account-vendor-utility combination means errors are not prevented at the point of entry, creating a continuous cycle of firefighting and customer complaints. ## Goals Key goals for the customer moving forward include: - **Achieving SOC 2 Type II Compliance:** To meet a contractual obligation and solidify trust with enterprise clients by obtaining this security certification within the next year. - **Establishing System Reliability and Data Integrity:** Implementing a systematic framework to define correct billing parameters for each account and proactively flag or block transactions that deviate from this setup, thereby preventing errors before they propagate. - **Eliminating Payment Failures:** Resolving the root causes of transaction failures with payment partners to ensure bills are paid reliably and on time, avoiding service interruptions for their operations. - **Executing a Strategic Cleanup:** Developing and enacting a plan to methodically review and correct historical data inaccuracies, particularly for key accounts, to restore confidence in the platform's analytics and reporting. - **Improving Proactive Monitoring:** Enhancing the use of existing analytics and reporting tools to proactively identify missing invoices or data anomalies before customers report them, shifting from a reactive to a proactive operational stance.

## **Summary** The meeting focused on strategies to enhance and expand the data ingestion ecosystem, primarily for utility invoice processing. A central theme was enabling new, automated points of entry for bill data from various sources, including internal Constellation networks and external third-party vendors, while streamlining and refactoring existing workflows to avoid redundant processing steps. The discussion covered technical architecture, deployment considerations, and specific implementation pathways for different data sources. ### **Enhancing Data Ingestion for Constellation Builds** The team examined methods to automate the retrieval and processing of customer bill data directly from internal Constellation sources. This initiative aims to bypass manual downloads and unnecessary Optical Character Recognition (OCR) processing by leveraging pre-extracted data. - **Current Integration & Strategy:** A connection has been established with the Data Access Gateway (DAC) team, providing access to a Databricks environment that houses Constellation bill data, including raw XML. The proposed approach involves creating a service that programmatically queries this source for available invoices based on customer accounts, pulling the data in bulk, and classifying it internally. - **Key Advantage:** This method provides greater control over the ingestion logic and timing, as the data container is continuously populated by Constellation independently. The team can design the pull mechanism to fit existing workflow schedules rather than relying on external notifications or fixed prescriptions from the data provider. - **Processing Goal:** The ideal end-state is for this ingested XML data to be transformed into a structured JSON format (similar to the VSS output) and fed directly into downstream systems without passing through the traditional DSS extraction pipeline, saving time and resources. ### **Architectural Deployment: Green Cloud vs. Red Cloud** A significant portion of the discussion was dedicated to determining the optimal hosting environment for the new ingestion services, weighing the concepts of "Green Cloud" and "Red Cloud" within the Constellation network. - **Fundamental Difference:** The core distinction lies in network trust and perimeter. **Green Cloud** resources are hosted within the internal Constellation enterprise network, allowing them to communicate freely with other internal services without firewall impediments. In contrast, **Red Cloud** resources are considered external, residing outside the trusted perimeter and must access internal services through strict, zero-trust authentication protocols, similar to any public third-party service. - **Strategic Decision Point:** The team debated whether to build the new service within the existing external ecosystem (analogous to the current FDG tenant) or as a greenfield project inside the Constellation tenant. Building internally (Green Cloud) offers smoother long-term integration as other systems migrate, but risks creating an isolated component if broader migration is delayed. The practical, short-term suggestion is to develop the service in the existing external ecosystem to accelerate delivery, acknowledging that firewall requests and ticketing processes will be required to access internal Constellation services from the outside. ### **Integrating Third-Party Vendor Data (e.g., Utility API)** The conversation expanded to include automated data pulls from external utility data aggregators, which present a similar architectural challenge but with different technical constraints. - **Use Case & Scope:** Services like Utility API can provide bulk PDFs and pre-extracted JSON data for a specific set of large utility vendors, covering areas like power and gas but not water or co-ops. This makes them suitable for targeted Proof of Concepts (POCs) rather than universal solutions. - **Proposed Implementation Flow:** The credentials stored in the system for a customer would be used to authenticate with the third-party API. The service would then fetch the electronic bills (PDF or JSON) for specified accounts and dates. A crucial design decision is to **avoid creating a separate, unique import flow** within the DDIS application. Instead, the goal is to leverage the existing DSS codebase to handle this new data source. - **Long-term Vision:** The objective is to treat vendor-specific API integrations as another automated data retrieval channel that feeds into a centralized, refactored ingestion workflow, maintaining consistency and reducing maintenance overhead. ### **Refactoring DSS Workflows for Future Flexibility** A consensus emerged on the need to modify the core Document Processing Service (DSS) to natively support these new, diverse data ingestion methods without relying on legacy processing steps. - **Bypassing Unnecessary Steps:** For data sources like Constellation XML or third-party JSON where extraction is already complete, the workflow must "short-circuit" the OCR and Intelligent Processing Service (IPS) steps. The data should flow directly to the transformation and population stages. - **Centralizing Logic:** The refactoring aims to make DSS the central hub for all data retrieval and initial ingestion. This creates a "black box" for other applications, which can simply request data without concern for its source. The service would use the shared database to determine client-vendor mappings and trigger appropriate fetch logic. - **Next Steps:** The immediate action is to begin the DSS refactoring project with these specific integration goals in mind, creating a flexible foundation upon which the Constellation and third-party vendor features can be built. ### **Enabling the UBM Drag-and-Drop Feature** The requirements for enabling a drag-and-drop invoice upload feature within the UBM (Utility Bill Management) application were clarified, highlighting it as a relatively straightforward integration. - **Minimal Requirements:** For a successful upload, the frontend needs to send the PDF file along with three key metadata points: Vendor Account Number, Client ID, and Vendor ID. These fields are helpful for routing but are optional; the system can attempt to derive them from the invoice content if not provided. - **Simple Integration Path:** UBM developers would need to call a single, well-documented DSS API endpoint. The process is designed to function like a "Dropbox," where the primary confirmation is a successful upload receipt. From there, the invoice enters the standard DSS processing pipeline. - **Authentication:** Access would be secured via a standard OAuth 2.0 flow, where UBM obtains a client ID and secret to generate tokens for API calls, a common pattern their developers are expected to be familiar with. The meeting concluded with alignment on the strategic direction: to refactor DSS as the central ingestion engine capable of supporting multiple automated data entry points, thereby enhancing efficiency and scalability for processing utility bills from an expanding array of sources.

## **Summary** ### **The Core Problem: Proliferation of Conflicting Reports** The central issue driving the meeting is the overwhelming number of disparate and unreliable reports for tracking invoice data and customer accounts, which has led to confusion, inefficiency, and a lack of confidence in the data. The absence of a single, authoritative source of truth makes it impossible to accurately manage client accounts, verify invoice receipt, and report on operational status. - **Multiple reports create chaos**: There are at least five different reports (e.g., Invoice Lifecycle, Invoice by Due Date Estimate, the legacy Lab/DSNUBM report, Client Account Status) all purporting to track similar data but yielding conflicting results. This leads to unproductive meetings where stakeholders debate which report is correct rather than solving problems. - **Critical data gaps are exposed**: A stark example is the Victra account, which has approximately 2700 accounts. However, key reports like the invoice downloads Power BI report show only about 900, and another legacy report shows only 65. This massive discrepancy underscores the severe lack of visibility into what invoices have been received, how they were obtained (web download, mail redirect, etc.), and their current status. - **The business impact is significant**: This data confusion prevents effective operations, hinders the ability to ensure all client invoices are captured, and damages credibility with both internal teams and external clients who receive inconsistent information. ### **Deep Dive into Existing Reports and Their Shortcomings** The discussion involved a live review of several specific reports to diagnose their failures and understand what data they actually contain. The goal was to assess which, if any, could serve as a foundation for a unified solution. - **Invoice by Due Date Estimate Report**: This report appears to be non-functional for current needs because it only shows tasks that require action, not a complete history of all processed invoices. It is therefore useless for creating a comprehensive account list. - **Invoice Lifecycle Report**: This report provides a more inclusive view of processed invoices but is structured around download dates rather than invoice dates, making it difficult for the operations team to use for their monthly reconciliation processes. Its filters and data sources need clarification. - **Legacy "Late Arriving Bills" (Lab/DSNUBM) Report**: This is the report specifically requested by the operations team as their historical source of truth. However, it seems to only display a subset of "late" bills. Even when filters are cleared, it shows a fraction of the expected accounts (e.g., 65 for Victra instead of ~2700), indicating it is either broken or fundamentally designed not to show all accounts. - **Client Account Status (Non-Tabbed) Report**: Among all reports examined, this one came closest to showing the expected volume of accounts for Victra (over 3100), though it includes duplicates and inactive/closed accounts. It was used as a temporary, stop-gap solution but is not considered the final answer. ### **Establishing a Unified Source of Truth** The primary resolution from the meeting was to designate and repair one central report to serve as the definitive source for all account and invoice data, consolidating the useful elements from the various existing reports. - **The chosen foundation is the Lab/DSNUBM report**: The team agreed to update and fix the legacy "Late Arriving Bills" report, as it is the one explicitly requested by the operations team. The objective is to transform it from a "late bills only" view into a complete master list of all accounts. - **Consolidation and archival plan**: To prevent future confusion, all other redundant or obsolete reports will be moved to an archive folder. Only a small set of vetted, unified reports will remain active, ensuring everyone references the same data. - **Immediate action items defined**: The development team will conduct a deep dive into the data sources and calculations powering the Lab report. This involves defining each column, verifying its source (e.g., UBM, DS, legacy SQL), and understanding calculations like "Short Payment Window Delay." Ambiguous or unverified columns may be hidden initially to launch a functional version faster. ### **Operational Challenges and Process Improvements** Beyond the core reporting issue, the conversation highlighted several adjacent operational and systemic problems that complicate data integrity. - **Account closure process is broken**: A significant issue is that accounts can be marked as closed in one system (e.g., UBM) but not communicated or reflected in another (e.g., Data Services). This leads to phantom accounts in reports and operational errors. The directive is to stop merely notating closures and to implement a systematic, cross-platform closure process. - **Handling of "Mock" invoices**: For clients like Victra, "mock" invoices are sometimes used as placeholders. The reporting system must be able to distinguish between mock and actual fiscal invoices, and flag accounts where a mock invoice is still pending replacement with the real one, to avoid giving a false sense of completeness. - **Automation with BDE**: There is a manual process for sending account closure and update CSVs to BDE. While an API integration was discussed months ago, it has stalled. The team will re-engage to scope out automating this data exchange, moving away from error-prone manual emails. - **Improving communication with Ops teams**: To address frustration over perceived slow progress on issue fixes, a new process was proposed: instituting weekly priority-setting meetings with the operations leads (like Afton and Rachel). This aims to align development priorities, demonstrate progress, and involve them in the process to build trust and manage expectations. ### **Client-Specific Data Issues and Broader Implications** The reporting problems are symptomatic of deeper data quality issues affecting specific, high-priority clients, raising concerns about contractual and reputational risk. - **Victra's missing invoices**: The discrepancy in Victra's account count is the most pressing example, but it reflects a company-wide problem of not having a reliable master account list for any client. - **Munson and St. Elizabeth audit pressures**: For these key clients, there is immense pressure to conduct a full audit of invoices, usage, and costs to satisfy channel partners and secure contracts. The team recognizes the task is monumental, as historical data is messy. The strategy is to focus on known problem patterns (e.g., propane cylinder line items, double-counted "use" and "use cost" entries) and audit those systematically, rather than attempting an impossible line-by-line review of thousands of bills. - **FreshMark escalation**: A query from the FreshMark client about a discrepancy between the number of invoices and "bill blocks" shown in the analytics tab has escalated rapidly within the organization. This underscores how data inconsistencies can quickly become major credibility issues requiring immediate attention. ### **Strategic Direction and Next Steps** The meeting concluded with a clear, agreed-upon path forward to regain control over data and reporting, emphasizing a move towards automation and systemic fixes over patching legacy processes. - **Fix the foundation first**: All efforts will be initially directed at creating the single, unified "source of truth" report based on the Lab report framework. This is the critical prerequisite for solving other problems. - **Move forward, not backward**: There is a strong consensus against merely fixing old systems to work as they did in the past. The goal is to build more automated, efficient, and scalable processes, even if it requires deprecating old, familiar reports. - **Embrace a unified view**: The future state involves having one master report with different tabs or filters (e.g., "All Accounts" vs. "Late Arriving Bills") to serve various needs, eliminating the redundancy that caused the current confusion. - **Develop a sustainable audit methodology**: For client-specific data issues, the team will work on developing a repeatable, logic-based audit process (e.g., flagging accounts that deviate from a defined "correct setup") that can be demonstrated to partners as evidence of diligent data management.

## **Planning for 2026: Strategic Initiatives and Core Challenges** This meeting was a strategic planning session focused on identifying and addressing critical issues in preparation for 2026. The goal was to catalog all major topics requiring attention-including customer expectations, sales and CSM requests, and internal technical debt-to avoid being blindsided by unforeseen challenges. Discussion centered on decoupling systemic pain points, improving visibility across platforms, and establishing a foundation for new features. The conversation emphasized moving away from reactive firefighting and toward proactive, systematic solutions. ### **Bill Pay Feature Isolation and Enhanced Visibility** A primary focus was on the need to separate the operational and reporting issues specific to bill pay customers from the general analytics customer base, as current dependencies mean priorities for one group negatively impact the other. - **Decoupling Bill Pay Pain Points:** A core strategy involves creating dedicated workflows and views for bill pay to prevent issues in that segment from disrupting service for other customers. This includes potential UI changes, like separate tabs for emergency payments, to clarify data. - **Developing a Forensic Bill Lifecycle View:** There is a critical need for a comprehensive view to track a bill from download through to payment. This "invoice life cycle" report would answer fundamental customer questions about whether a bill was pulled, if it was late, and the reason for any delays, aiming to replace manual, week-long investigations with instant, asynchronous data access. - **Integrating Payclearly Data:** Work is underway to integrate Payclearly's API endpoints to pull funding and check reconciliation data. A temporary daily extract solution is in place, with a goal to move toward real-time updates via webhooks, ultimately enabling automatic matching of batch funding information with deposits. ### **Errors, Validations, and Manual Process Automation** The current approach to data errors and validations is creating significant manual overhead and needs a complete review, especially to differentiate between bill pay and other customers. - **Comprehensive Review of Validations:** A planned workshop with operations teams (Tim, Tara, Mary) is needed to audit all existing error checks and validations. The goal is to determine what still makes sense, what is bill-pay specific, and to establish a clear workflow for bulk fixes to avoid creating backlogs. - **Addressing Systemic Data Issues:** Many data integrity problems stem from validations outside the current "integrity check" scope. The focus is on moving beyond one-off fixes to establish automated, bulk-resolution capabilities before turning on stricter validation rules for postpaid customers. - **Long-term AI Strategy for Smarter Validations:** Looking beyond 2026, there is interest in exploring AI to create smarter validation rules that go beyond simple one-to-one matching, potentially addressing complex issues like duplicate payment detection and virtual account mapping. ### **Data Flow and Virtual Account Challenges** Inconsistent data flow between systems (DSS, DDS, UBM) and the problematic "virtual account" logic are root causes of many data quality and reporting issues. - **Refactoring System Handoffs:** A key initiative is improving the integration and handshake process between UBM, DSS, and DDS, including refactoring the output service. This aims to ensure consistency and reliable data transfer. - **Re-engineering the "Bill Template" Concept:** A proposed solution to virtual account proliferation is to reintroduce and modernize the "bill template" or "setup bill" concept from DDS into DSS. This template would provide a consistent context (e.g., meter ID, account attributes) for all subsequent bills from the same vendor and account, instructing AI processing to inherit these attributes even if they are missing from the PDF. - **Linking Data Across Three Systems:** To troubleshoot issues efficiently, there is a need to develop a view that can merge the history of a single bill across DSS (AI-processed JSON), DDS (manual updates), and UBM (final state). This tri-system visibility would drastically reduce the time to diagnose why a bill is "wrong." ### **Reporting Engine and API Development** The reporting infrastructure is being modernized to provide more flexibility and self-service capabilities for both internal teams and customers. - **Building a Read-Only Reporting API:** The team is proceeding with a spike to create an API that exposes the existing reporting database views. This API-first approach, hosted within Kubernetes for environment-agnostic deployment, is valued for enabling future customer integrations and is targeted for development by May. - **Evaluating a Drag-and-Drop Report Builder:** While the API is a priority, the additional value of a user-friendly UX layer (a drag-and-drop report builder) on top of it is under evaluation. A stronger business case with specific customer examples is needed to prioritize this over providing the API and having internal resources build custom reports as needed. ### **New Feature Exploration: Contract Management** A completely new module for contract management was introduced as a strategic initiative for premium customers, requiring ground-up design and development. - **MVP as a Document Management System:** The initial phase is envisioned as a document repository within UBM, similar to the bills tab, where customers can manually upload contract PDFs and associate metadata (vendor, utility type, contract start/end dates, pricing type like fixed or index). - **Future Integration and AI Processing:** The long-term vision includes integrating with Constellation's systems to automatically pull contract data for their customers and potentially using AI to classify contract terms from PDFs. Initial efforts will focus on defining the data model and UI without being blocked by external legal approvals.

## **Data Services Report Crisis and the Need for a Single Source of Truth** The central and most urgent topic of the meeting was the complete breakdown in reliable reporting from Data Services (DS). Multiple reports (like the "lab deriving bills report" and "invoice download report") are either non-functional, outdated, or incomprehensible to the operations team, leading to a critical lack of visibility. This has resulted in heated external meetings where teams cannot account for invoice statuses, directly threatening client relationships and revenue. - **Multiple Broken Reports:** There is no single, reliable report to track all customer accounts and their last invoice download dates. Teams are forced to scramble between different, confusing reports (e.g., "invoice due date estimate," "lab deriving bills"), none of which provide a complete or accurate picture. - **Operational Blindness:** This reporting failure means the team does not know which invoices are late, which have never been downloaded, or the overall status of accounts. A specific example was the discovery of 957 accounts in a report for Victra, a client known to have far more, highlighting the data discrepancy. - **Immediate Demand for Resolution:** The immediate action required is to identify, clean up, and establish **one definitive report** that serves as the sole source of truth for invoice status and account management. The preference is to fix and use the existing "UBM Billing Accounts" report if possible, rather than create a new one. ## **Critical Client-Specific Invoice Emergencies** Several key clients are at risk due to processing delays and errors, with serious financial and legal consequences. The team is actively firefighting these situations, which are exacerbated by the poor reporting. - **Victra's Duplicate "Special" Invoices:** Two invoices for the same Victra account were incorrectly processed as "special," risking non-payment and service disconnection. The root cause is unknown, and it requires emergency attention to prevent account shutdown. - **Medline's Imminent Legal Threat:** Medline is explicitly threatening to sue over unpaid invoices. The contract is relatively small, leading to a stark assessment that the company might be better off canceling it rather than facing legal costs. Daily clearing of Medline invoices is now an absolute priority to avoid escalation. - **Bannon's Contractual and Processing Standoff:** Bannon is requesting an extension to process invoices through April, but the team is firmly capping it at the end of February. A further complication involves Bannon asking for confidential bank account information sharing with another supplier (PayCleary), a request that was firmly denied. - **Jacob's Neglected Backlog:** The Jacob account has a significant backlog of invoices (starting at ~400) that has been largely ignored. While some progress has been made, the impending influx of 800 newly discovered missing accounts threatens to inundate this workflow completely. ## **Systemic Gaps Between Data Services and UBM** Underlying the reporting crisis is a deeper, systemic disconnect between the Data Services (DS) system, the DL Helper tool, and the UBM platform. This architectural flaw is the root cause of missing accounts and inaccurate tracking. - **The "800 Missing Accounts" Problem:** A major issue identified is approximately 800 accounts where credentials exist in DL Helper but are not properly linked as tasks for download in Data Services. This means the accounts are technically in the system but are invisible to the download team's workflow. - **Dichotomy of Systems:** The DL Helper (where downloaders work) and Data Services do not perfectly sync. An account can exist in UBM/DS but not in DL Helper, and vice-versa. This leads to a fundamental mismatch in what each team considers the "source of truth" and causes accounts to be missed entirely. - **Linking as a Temporary Fix:** A proposed immediate workaround is to prioritize bulk-linking activities between systems to close the gap, though a permanent architectural solution is needed. ## **Team Coordination and Workload Management** In response to the crises, the discussion focused on re-allocating team resources to tackle the most pressing client backlogs and establish clearer internal processes. - **Prioritizing High-Risk Clients:** Specific personnel were assigned to focus exclusively on critical accounts: two people dedicated to Extension, attention shifted to Jacob, and Karen tagged for Medline. The team on Bannon continues its work. - **Clearing Ops Review and Closing Accounts:** A process issue was highlighted where accounts needing closure are stuck in "Ops Review" instead of being formally closed in the system and synced to Data Services. The directive is to bulk-close where possible and clean up linking afterward. - **Staffing Adjustments:** New downloaders are being onboarded to the DL Helper team to increase capacity. Internal training is also happening, such as cross-training Jacqueline on bill pay tasks to help with the workload. - **Communication Protocol:** A clarification was made that client invoice requests should be routed through a single point of contact (Afton) to manage properly, rather than going directly to individual data specialists, to maintain accountability and visibility.

## **Summary** The meeting centered on improving data processing systems, with a strong focus on fixing integration issues, enhancing application functionalities, and clearing the path for deploying tested features to production. Key topics included resolving a critical data ingestion problem with a specific vendor, implementing user tracking in an upload system, and finalizing a major user interface upgrade for bill management. The team also reviewed the status of several tickets in testing and planned their deployment. ### **Constellation Invoice Integration & Data Improvements** A persistent issue with automatically processing invoices from Constellation was addressed, alongside requests for historical data from other vendors. The system has been incorrectly identifying services ("hallucinating") during IPS processing despite having the correct information. The plan is to use an official Constellation API to fetch XML invoices, convert them to the required JSON format, and push them to DSS to ensure timely and accurate billing. Additionally, there was a request for historical CSV data from Hexable (and potentially other vendors like St. Elizabeth and Manson) to analyze past discrepancies, highlighting that manual verification had previously uncovered errors needing correction. ### **FTG Connect User Attribute Tracking** Progress was reported on a ticket to record which user uploads a bill via FTG Connect's individual upload function. The current system logs the creator as "File Watcher" in the primary database, obscuring the actual user. The solution involves adding a new column in the DSS UI to display the true user who initiated the upload. Development was temporarily hindered by debugging basic functionality errors in the local FTG Connect environment, but the approach is clear and work is expected to resume. ### **DSS Web Downloader: Client View Enhancement** A significant enhancement to the DSS Web Downloader was presented and deemed ready for production. The update introduces a "View by" dropdown, allowing the operations team to filter and view bills grouped by *client* in addition to the existing vendor-based view. This solves a major operational pain point where gathering all bills for a single client required searching across multiple vendors. The implementation includes full sorting functionality (alphabetical, invoice count) and correctly filters the bill list based on the selected client. A related credential management page currently remains vendor-focused, which was noted as a potential future enhancement. ### **Testing Review & Production Deployment** Several completed features in the testing environment were reviewed for final validation and deployment approval: - **Duplicate Invoice Check:** A feature to check for duplicates based on invoice date, due date, and amount after DSS processing was confirmed as complete. - **IPS Status Filters:** New filters in DSS for "Complete" and "Failed" build statuses from IPS were tested and approved for deployment. This required coordination to ensure changes were synchronized across the IPS, DSS API, and UI. - **Build Status Column & Archiving:** The addition of a "DSS Status" column to the UI and a new archiving function for bills were demonstrated. The archive feature successfully hides bills from the main list, with an option to unarchive them. - **Other Tickets:** Items like upload tracking for file exchange and late fees separation were verified as done, while a redirect for pre-audit failures was identified as requiring a specific user action to fix. ### **Tool Overview & Documentation Gap** A high-level overview of the DSS Web Downloader tool was provided for context. Its purpose is to assist the operations team in managing the periodic download of client bills from various vendor portals using stored credentials and then uploading them to data processing systems. It was acknowledged that comprehensive technical documentation for this application does not currently exist.

## **Double-Counted Usage: The Primary Data Integrity Issue** The most significant and recurring problem identified was the double-counting of energy consumption within bill data. This error inflates total usage figures, leading to inaccurate reporting and analysis. - **Manifestation in various forms:** The issue presented itself in two main ways. First, within a single billing line item, both a 'use' observation (e.g., kWh) and a 'use cost' observation were incorrectly captured for the same consumption. Second, entire bill components that should have been separated (like supply and distribution) were incorrectly combined into a single "full service" block, causing their usage to be counted together incorrectly. - **Correction methodology:** The established fix is to **remove the standalone 'use' observation line and retain only the 'use cost' line**. This preserves the financial data while eliminating the duplicate consumption entry. The discussion noted a historical shift in how data services captured this information earlier in the year, moving away from a method that used specific 'build use' observation types to prevent double-counting. ## **Full Service vs. Distribution/Supply Breakdown** A critical diagnostic step involves correctly classifying bill types. Mislabeling is a root cause of linking failures between related accounts and of the double-counting issue. - **The "Full Service" mislabeling trap:** A common error is labeling a bill as "full service" when it should be designated as either "distribution" or "supply." This is crucial even for bills that only contain distribution charges, as they must be correctly categorized to later link with a separate supply bill from another provider. Incorrect labeling prevents this automated linking. - **Impact on system integrity:** When bills that should be separate are incorrectly combined under a full service label, it creates systemic errors that cascade through reporting and prevent accurate account reconciliation. ## **Propane and Special Commodity Cases** Processing bills for propane and similar fuels presents unique challenges that require manual scrutiny and specific rules, distinct from standard electric or natural gas bills. - **Service period complexity:** For delivery-based fuels like propane, the service period on a bill must align with the delivery period, spanning from the end date of the last delivery invoice to the end date of the current one. This often requires cross-referencing multiple statements and delivery tickets rather than taking the dates on a single bill at face value. - **Vendor-specific data quality:** The clarity of billing data varies significantly by supplier. For instance, Amerigas bills are typically straightforward, while other suppliers like Ferrellgas may have overlapping or confusing billing statements that demand extra attention to ensure accurate period alignment. ## **Mislabeled Electric and Lighting Accounts** Improper categorization of specific utility account types prevents them from being tracked correctly within the system, as they are designed to be managed separately. - **The consequence of incorrect utility types:** A frequent error is labeling "lighting" accounts as standard "electric." Since lighting (often for outdoor areas) is a distinct utility type, this mislabeling breaks the automated linking process. The same principle applies to other utilities, such as labeling "irrigation" or "fire protection" water lines simply as "water." - **Identifying clues on the bill:** Key indicators for identifying a lighting account include the rate code (often containing abbreviations like "OL" for outdoor lighting) or descriptions in the line items mentioning "lamps," "LED," or "halogen." ## **Historical Data and Mock Bill Issues** A significant data quality gap exists for historical bills imported into the system, which compromises the accuracy of any longitudinal analysis or reporting. - **The mock bill problem:** Historical data is often imported via spreadsheets and used to generate mock bills. A major flaw in this process is that these mock bills frequently capture only the cost information while omitting the corresponding usage data (kWh, therms, etc.). This renders the historical record incomplete and useless for meaningful consumption analysis. - **Compounding future reporting risks:** The prevalence of uncorrected data errors (like double-counting) in current bills, combined with incomplete historical data, sets the stage for a systemic crisis. This will likely surface when clients begin year-end reporting and reconciliation, potentially leading to a large-scale, urgent correction effort.

## Customer The customer is part of a specific business unit (UBM) within a larger organization that is engaging in a SOC 2 Type II compliance assessment. The individual leading this effort is newly stepping into a role overseeing security and compliance processes, with a focus on consolidating and improving existing frameworks that had been managed across different parts of the business. Their background involves coordinating between engineering, operations, and external partners to establish a more efficient and sustainable compliance program. ## Success A significant prior success highlighted was the strategic decision to unify the compliance effort across all business units under a single external auditor. This consolidation is viewed as a major efficiency win, simplifying the audit process and creating consistency. Furthermore, there is an existing foundation of automation within their compliance processes, particularly in evidence collection, which indicates a mature starting point and a commitment to leveraging technology over manual effort. ## Challenge The most pressing challenge expressed is the significant internal time and resource drain caused by manual compliance activities. The team has been spending an excessive amount of time collecting and managing evidence for audits. This manual overhead is a key pain point the customer is determined to solve, with a clear directive to identify and automate any feasible processes to free up internal engineering and operational resources. ## Goals The customer's primary goals for the engagement are: - **Minimize Internal Effort:** To drastically reduce the time and manual work the internal team dedicates to compliance evidence collection and questionnaire responses. - **Maximize Automation:** To aggressively identify and implement automation opportunities, especially by integrating various systems (like GitHub, AWS, Azure, HR ISPs) into their GRC tool (Vanta) to enable automated control testing. - **Streamlined Process Integration:** To establish a clear, efficient workflow where policies are drafted by the partner, reviewed internally, and managed within their GRC platform with minimal back-and-forth. - **Achieve Timely Compliance:** To successfully complete the SOC 2 Type II audit within a targeted timeline, while being mindful of and aligning with other major internal initiatives, such as a large-scale migration to Azure.

## Customer The customer is a client in the energy and sustainability sector, relying on a comprehensive AI-powered platform for processing and analyzing utility bills (electricity, natural gas, propane, water) across a large portfolio of facilities. They use this data for critical financial planning, reporting to leadership, and advising their own clients, placing immense importance on data accuracy and reliability for maintaining their trusted reputation. ## Success The most significant success highlighted was the platform's role in **averting a major reputational and financial crisis**. When faced with an impending external audit for a key client (Hexpo), the team was able to leverage the system to conduct an intensive, manual validation over a weekend. This effort identified and rectified critical data errors. The intervention was described as "pulling it out of the fire," directly preventing potential severe consequences, including the risk of losing the client or damaging crucial professional relationships. This episode demonstrated the platform's underlying utility as a tool for deep forensic analysis when mobilized correctly, showcasing the vendor's commitment to partnership in a crisis. ## Challenge The most pressing and systemic challenge is **ongoing data inaccuracy and inconsistent ingestion processes**, which severely undermines trust and creates excessive manual workload. Several core issues persist: - **Accuracy Problems:** Errors like mis-mapped propane cylinder units, duplicates, missing data, and commodity-specific issues (e.g., with natural gas) have been found even in recently onboarded clients. This casts doubt on the integrity of all historical data and current dashboards used for financial planning. - **Process Breakdowns:** Bills are experiencing significant delays in ingestion-sometimes taking eight weeks or more-requiring constant manual chasing by the customer's team. The existing process lacks transparency, making it difficult to see where a bill is stuck. - **Resource Drain:** The customer's team is burdened with continuous validation work and troubleshooting, described as "wearing down." This distracts from their core advisory role and creates operational inefficiency. The root cause of these recurring issues is not fully transparent, leading to concern that problems will repeat across the entire client portfolio. ## Goals The customer's immediate and near-term goals are centered on restoring confidence and achieving operational stability: - **Validate Portfolio Integrity:** Extend the validation exercise performed for Hexpo to other major clients (specifically Munson and St. Elizabeth) to understand the scope of data issues and confirm their data is "airtight." - **Achieve Reliable Baseline Data:** Move beyond crisis management to a state where the core data in the system can be trusted implicitly for reporting and client advisement. - **Implement Transparent Processes:** Receive clear timelines and plans for systemic fixes, including improved controls, QA steps for AI-processed data, and better status tracking for bill ingestion. - **Reduce Manual Overhead:** Implement platform improvements that significantly reduce the need for their team to manually track missing bills, validate line items, and chase down errors.

## Current Credential Management and Sync Process The meeting began with a detailed explanation of the current, manual process for synchronizing vendor credentials between the Data Services (DS) database and the UBM system. This process is foundational to how client access is currently managed. - **Daily Manual Sync:** Credentials, including login, password, and URL for each client account, are extracted from the DS database into a CSV file. These are then processed and individually updated or inserted as separate attributes within the UBM platform on a daily basis. - **Handling Shared Accounts:** A notable complexity in the process is that a single vendor account can be associated with multiple UBM clients. The system is designed to map these relationships correctly during the sync. - **Absence of Smartsheet Integration:** It was confirmed that the Smartsheet platform, which is used by other teams, is not currently part of this credential synchronization workflow. ## Critical Security Issue: Internal Portal Credential Exposure A primary focus of the discussion was addressing a significant security vulnerability involving a specific email account (`opsai@...`) used for an internal energy management portal. - **Widespread Unauthorized Access:** The credential for the internal "Energy Manager" portal was found to be synced to approximately 279 different customer accounts within UBM. This meant that if the exposed password was used, an individual could potentially access Constellation utility bills for all UBM customers. - **Source of the Problem:** The credential was actively being pulled from the Data Services database and propagated through the daily sync into the UBM environment. Simply deleting it from UBM would not be a permanent fix, as the sync would repopulate it the next day. - **Immediate Risk Mitigation:** The urgency of the situation was underscored by the fact that the password had already been shared with an unauthorized party, necessitating immediate changes to both the sync process and the credential itself. ## Immediate Actions and Resolution Plan A concrete, immediate action plan was agreed upon to remediate the security vulnerability and prevent its recurrence. - **Removal from Sync Source:** The first and most critical step was to modify the source data scripts used for the daily sync to permanently exclude the `opsai@...` login credentials, preventing them from ever being re-synced into UBM. - **Cleanup of Existing Data:** Following the change to the sync process, the existing entries for this credential would be purged from the UBM production database to remove any outdated and compromised passwords from the system. - **Credential Rotation:** With the sync stopped and the old entries removed, the team would then proceed to change the actual password for the `opsai@...` account, fully securing the internal portal. ## Systemic Challenges and Lack of a Single Source of Truth The conversation highlighted broader, systemic issues within the organization's credential management, which contributed to the security incident and operational inefficiency. - **Disconnected Systems:** Three separate platforms-Data Services (DS), UBM, and Smartsheet-are each treated as a source of truth by different teams (Data Services, UBM Ops, and CSMS, respectively). These systems do not communicate changes automatically. - **Inconsistent Update Paths:** For example, when customers report credential updates to the CSMS team, changes are made only in Smartsheet and are not automatically propagated to DS or UBM, creating data inconsistency and reliability issues. - **Manual Workarounds:** The current daily sync process was established as a manual bridge between DS and UBM, but it does not incorporate Smartsheet, leaving a gap in the data flow and requiring manual intervention. ## Future Direction: Automation and Centralized Management To address the root causes of the disconnect and inefficiency, the discussion concluded with a vision for a more robust, automated solution. - **Proposal for a Centralized Database:** The proposed long-term solution is to establish a single, separate credential database that serves as the definitive source of truth for all systems. Any update in this central repository would be automatically propagated to UBM, DS, and other platforms. - **Enhanced Metadata:** This central system could also include valuable metadata, such as "last updated" timestamps, providing much-needed audit trails and simplifying credential lifecycle management. - **Automation of Manual Processes:** While the current manual sync was acknowledged as not overly time-consuming, its automation was agreed to be beneficial for consistency and to eliminate the risk of human error or forgotten updates. However, it was noted that this automation work is often deprioritized against other development tasks. - **Technical and Operational Hurdles:** Beyond the technical build, the main challenge identified is operational: aligning the different teams to agree on and use a common source of truth, overcoming the existing siloed ownership of credential data.

## Summary The meeting centered on addressing several critical operational challenges currently impacting the business, with a strong emphasis on data integrity, payment processing accuracy, and procedural security. Key discussions revolved around resolving widespread data issues for a major client, mitigating urgent payment and disconnection problems, and addressing a significant security vulnerability. The team also reviewed recurring payment errors and planned for standardizing onboarding processes. ### Ongoing Data and Operational Issues The team is managing severe data and operational challenges, primarily with a key account (URA), which has required extensive manual correction work. - **Major Client Data Cleanup:** A significant effort was required over the previous weekend to fix numerous data issues for the URA account. Problems included incorrect data captures, usage discrepancies, unit of measure errors, and invoice number mistakes, particularly affecting natural gas and propane bills where inconsistent vendor conversions caused widespread calculation errors. - **Urgent Payment and Disconnect Notices:** Several accounts, including Medline and Ascension, are at risk due to late payments and potential disconnections. Medline, with approximately 300 outstanding invoices, represents a critical failure point, as the company has been a client for a year and has portal access, making these delays unacceptable. The team is actively working to process a backlog of invoices to prevent further late fees and service interruptions. ### Security Vulnerability in Third-Party Portal A serious confidentiality breach was identified involving shared login credentials for the Constellation EnergyManager (CEP) portal. - **Exposed Credentials:** The shared username and password for the internal Constellation portal, which provides access to all client commodity data, was emailed to an external party. This poses a major contract and confidentiality risk. - **Required System Fix:** An immediate fix is required in the data synchronization process to ensure these shared credentials are excluded from being visible within the internal UBM platform. A password change is also necessary, but the sync logic must be corrected first to prevent the new credentials from being exposed again. ### Analysis of Duplicate Payments and Process Errors A review of duplicate payments revealed systemic issues in the billing and payment process that extend beyond automated data repairs. - **Root Causes Identified:** Duplicate payments were caused by a combination of automated system errors (e.g., auto-mapping of unmapped bills) and human errors, such as incorrectly zeroing out actual invoices instead of mock bills after payment. A specific analysis of one list showed credits on accounts beyond what was initially reported, indicating more widespread problems. - **Client Pressure and Pushback:** Clients like Victor are now pushing back on practices such as creating mock bills and emergency payments. The team acknowledged that while they may agree to stop these practices temporarily, the underlying issues related to not having Electronic Data Interchange (EDI) feeds are a root cause of the discrepancies. ### Standardizing Onboarding and Operational Procedures The need for standardized processes, particularly for client onboarding, was highlighted as a critical step to prevent recurring operational failures. - **Upcoming SOP Meetings:** A two-day meeting is scheduled for January 13th and 14th to establish Standard Operating Procedures (SOPs), with onboarding being the first and most critical focus area. The current lack of clear timelines and consistent processes for onboarding is identified as a primary source of delays and errors downstream. - **Need for a Testing Protocol:** The team discussed the lack of a robust testing protocol for large-scale data fixes before they are executed in the production environment. The consensus was to start using a staging or test environment to validate the outcome of major batch operations, such as past due amount adjustments, before implementing them live to prevent errors affecting client accounts. ### Miscellaneous Administrative Updates Brief updates were provided on internal resource allocation and administrative tasks. - **Resource Re-allocation:** An employee (Benny) is being moved to focus on downloading actual usage data for key, high-priority clients to ensure those tasks are completed. - **Administrative Tasks:** A new laptop and docking station were requested for an employee experiencing hardware issues, and the process for ordering through the internal system was confirmed.

## Summary ### Holiday Schedules and Resource Availability The meeting opened with a discussion about upcoming holiday schedules and their impact on team availability, particularly for development work in late December and early January. Several national holidays were noted, and it was acknowledged that team members would have varying availability, requiring coordination. The importance of checking schedules with all team members, including those from external partners like Cognizant, was emphasized to ensure project continuity. Key individuals like Ruben, Dan, and Mitchell were identified as potentially available to manage infrastructure needs during this period. ### Strategic Planning for Q1 and H1 The core of the meeting focused on strategic planning for the first quarter and first half of the year for the UVM platform. The primary goal is to identify initiatives that will make a significant impact on bill pay customers and reduce the engineering time spent on repetitive tasks. A key area of focus is reducing the 30-40% of engineering capacity currently consumed by certain manual processes. The discussion aimed to move from high-level goals to a concrete, prioritized list of projects that could be realistically accomplished given time and resource constraints. ### Analyzing and Streamlining Customer Onboarding A significant portion of the conversation was dedicated to dissecting the current customer onboarding process to identify bottlenecks. While initially perceived as a major engineering burden, it was clarified that the bottleneck isn't necessarily engineering itself but depends on the customer type. The main engineering touchpoints were identified as: - **AP File Configuration:** For customers with custom ERP systems (e.g., AppFolio, Oracle), engineering is needed to create customized AP files. Work is already underway to expose configuration to operators, and a future initiative involves consolidating common ERP templates into documented, generic solutions to minimize custom development. - **Custom Reporting:** The need for customer-specific reports (like for MedXL or Simon) requires engineering work due to a lack of a self-service reporting framework. A potential long-term solution discussed is building a flexible, drag-and-drop reporting interface for customers, though this requires technical discovery regarding database limitations. ### Reimagining the Bill Pay and Validation Workflow A deep dive was taken into the bill pay process and its associated data validations. The current system's main challenge is that all validations block payment, causing delays for bill pay customers. A proposed solution is to implement a **two-tier validation system**: - **Tier 1 (Critical Validations):** These would be a subset of validations (e.g., data integrity checks) directly tied to the accuracy of the payment amount and AP file generation. *Only these validations would block a bill from being paid.* - **Tier 2 (Analytical Validations):** This tier would include other data verification and audit checks important for reporting and analytics. Bills could be paid even with these outstanding issues, with operators resolving them retroactively. However, critical implementation challenges were raised, particularly around the **synchronicity between bill pay files and AP files**. Once a bill is paid, most data related to costs cannot be changed retroactively without creating discrepancies. The only retroactive changes deemed feasible are those related to *usage data*, which affect analytics but not financial reconciliation. ### Engineering Resource Planning and Project Pipeline The conversation concluded with immediate concerns about engineering bandwidth for the upcoming January sprint. There is a specific need to identify valuable work for front-end and design resources, as many of the discussed initiatives (data workflows, AP file templates) are backend-heavy. The existing backlog may not provide enough substantive work for the full team. Several potential projects were floated to address this gap: - **API Development:** Exposing certain platform functionalities via API was mentioned as a possible project. - **Historical Build Analysis:** Investigating past data builds was noted as another backlog item. - **Interpreter Layer ("SS" Project):** A related initiative to build an interpreter was briefly mentioned, which aligns with improving the data handshake process between platforms. This project could involve both front-end and back-end work. The agreed-upon next step is to compile all discussed ideas-from high-level strategic goals to specific technical enhancements-into a single document for prioritization and preliminary solutioning in a follow-up meeting.

## **Ticket Updates and Progress** The meeting primarily focused on reviewing the status of several development tickets across the FTG Connect and DSS applications. Significant progress was reported, with multiple features now ready for or undergoing testing. - **Dynamic Button for Carrying Files**: Changes for this feature have been successfully applied and are working on the Deviant test server, ready for verification. - **MPG Setup and Vendor Sorting (DS19)**: Work to sort the vendors list by invoice count in the bills processing tab is complete. This update has been deployed to the development and test environments on FTG Connect. - **Smart Filtering Button (DS29)**: Development for a button to enable or disable filtering for clients and vendors on the uploads page is finished. The feature is currently in the testing phase across various scenarios, with a deployment target for the following day. - **Formatting and Data Cross-Verification**: Work was completed on tickets related to peer DSS formatting and verifying the interconnection between client and vendor data, with statuses updated in Jira. - **FTG Connect Client View Update**: Development has begun on adding a client view to the build processing section. An API call to fetch the client list has been created, and a dropdown to switch between client and vendor views has been integrated. Some debugging on the API is currently underway. ## **Deployment Processes and Environment Access** A detailed discussion clarified the deployment pipeline for the FTG Connect application and highlighted a current access limitation. - **FTG Connect Deployment Pipeline**: The confirmed process involves deploying first to a development environment, then to a "producer" stage, and finally to a preview server on "digi" for testing before production. This clarity helps in planning future releases. - **VPN Access Limitation**: A blocker was identified in accessing the lower test environments (like dev and test producer) due to a mandatory, non-disablable VPN on the corporate laptop. This prevents immediate verification of the deployed changes, requiring an exception or alternative access method to be arranged. ## **Team Coordination and Upcoming Priorities** The conversation outlined immediate next steps and shifted focus toward future project work, accounting for current team availability. - **Production Deployment Responsibility**: Given the access constraints and existing context, it was decided that another team member would handle the deployment of the completed FTG Connect changes to production for the time being. - **Team Availability**: It was noted that a key team member was out sick but available for emergencies, slightly impacting the day's collaboration dynamics. - **Transition to DSS Application Work**: Once the current batch of FTG Connect "pain point" tickets is completed and deployed, the development focus will shift back to the DSS application. The goal is to address usability issues that the team encounters when handling tickets within DSS, which is anticipated to be a substantial next phase of work. ## **Immediate Follow-ups and Additional Tasks** Several specific action items and minor tasks were surfaced to be handled immediately after the meeting. - **Jira Ticket Updates**: All developers confirmed they had updated the status of their respective tickets in Jira, moving them to testing with appropriate comments, which allows for proper tracking and handoff. - **Attachment for Ticket DS45**: An issue was raised regarding a video upload in a Constellation account (ticket DS45). The relevant video file was downloaded during the call to be attached to the corresponding Jira ticket, which should help in diagnosing the problem. - **Future Task Assignment**: While more FTG Connect changes are desired, new tasks for the following day will primarily be assigned from the existing backlog in Jira. Communication for any additional details or issues will be facilitated through Slack for efficiency.

## **Billing Account Attributes Update Process** This section covers the core method for updating customer login credentials within the system. Updates are managed through a bulk file upload process. A specific file, often received from users like Rachel Ramp and others, is used to update the `login` and `login password` attributes associated with billing accounts. The system has a dedicated bulk upload functionality within the data admin section. The process uses a file where each row contains a unique **billing account ID**; the system then updates only the attributes for the accounts listed in that file. After an upload, it is standard practice to manually refresh the connected Power BI report data to verify the changes have been processed correctly, even though the report is set to update automatically twice daily. ## **Automation and System Syncing Discussions** The conversation explored opportunities and challenges related to automating the update flow and maintaining data consistency across different platforms. There is a strong interest in automating the manual file-based process, especially after a clarifying discussion with a colleague named Ray, which indicated the automation could be straightforward. A significant concern was raised about potential data silos and lack of synchronization. Specifically, there is a possibility that Customer Success Managers (CSMs) might be updating credentials directly in a **Smartsheet**, without those changes being reflected in the primary system (UBM) or communicated to the operations or data services teams. This creates a risk of discrepancies and errors being discovered too late. A key next step is to investigate and establish a unified process for handling credential updates across all touchpoints. ## **OPS FBAI Email Group Function** The purpose and current use of a specific email distribution list within the system's ecosystem were clarified. The `OPS FBAI` email group has a very limited role within the primary application. Its main function is to serve as a recipient for automated system notifications. These notifications are primarily related to payment processing errors, such as when a bill is excluded from a payment file. The group essentially acts as an alert mechanism for the operations team regarding payment issues. ## **Short-Term Fixes and Operational Priorities** Updates were given on immediate tasks and pressing operational concerns that require attention. Files related to short-term fixes were prepared for distribution to the relevant team. An urgent operational concern was highlighted regarding **unmapped virtual accounts**, which is considered a high-priority issue that needs resolution. The team is awaiting the return of a colleague to help address the backlog of fixes and provide some breathing room for the team. ## **Meeting Logistics and Scheduling** A minor adjustment was made to the schedule for an upcoming discussion. A meeting concerning **funding analysis** was rescheduled to start a half-hour earlier than originally planned to accommodate participants' availability.

## Customer The customer operates within a sector that requires precise tracking and reporting of utility consumption, specifically for commodities like natural gas, propane, and water. Their background involves managing a multi-site portfolio where accurate data is critical for internal reporting, compliance, and likely emissions auditing. The discussion reveals a deep operational need for reliable data to support environmental, social, and governance (ESG) or similar regulatory narratives for senior leadership. ## Success The primary success identified was the proactive and thorough identification of data discrepancies through a detailed audit exercise. The process successfully pinpointed specific inaccuracies across several commodities, transforming what was previously assumed to be correct data into a far more accurate and auditable dataset. This exercise is considered a necessary and valuable step, ultimately leading to a higher degree of confidence in the reported figures. The collaborative effort resolved several issues, including incorrect manual entries and misinterpretations of billing structures, thereby strengthening the integrity of the foundational data. ## Challenge The most significant and recurring challenge centered on **propane data management**. The core issue was the lack of a standardized conversion method across multiple vendors. Each propane supplier uses different definitions for cylinder sizes and weights, causing major inconsistencies when the data was captured using a single, uniform conversion logic. This vendor-specific variability directly impacted the accuracy of consumption reports. A secondary, though less pervasive, challenge involved reconciling historical bills where usage data was missing, requiring manual retrieval or estimation to complete the dataset. ## Goals The customer's goals, as reflected in the conversation, are clear and focused on data integrity and reliable reporting: - To achieve and maintain **100% data accuracy** across all utility commodities (natural gas, propane, water) for all operational sites. - To establish a **robust and auditable data foundation** that can withstand internal and external scrutiny, particularly for emissions reporting. - To **eliminate future variances** in reported figures by implementing lasting fixes, such as vendor-specific conversion logic for propane. - To enable clear and confident **communication with senior leadership** by having a verified, accurate dataset and a clear narrative for any historical corrections.

## Summary The meeting primarily focused on resolving critical operational and security issues related to the procurement and handling of Constellation energy invoices. ### Constellation Invoice Automation Breakdown The core issue is the failure of an automated system for dropping Constellation bills into the company's workflow. A system that once functioned automatically for certain electric accounts has stopped working, leading to manual intervention and delays in processing invoices for customers like Park Ohio. The root cause of why the automation stopped and which specific accounts were ever covered remains unclear, highlighting a significant knowledge gap within the team. The failure of this automation is causing ongoing problems, requiring manual checks and creating a risk of late payments for clients. ### Customer Tagging and System Confusion A related problem involves a legacy "tagging" system for Constellation customers, which was believed to facilitate the automated process. This system appears to be poorly documented and misunderstood. Key personnel who were previously involved are no longer available or cannot recall how the tagging functioned, and the system's logic may have been broken by corporate actions like customer name changes (e.g., Park Ohio). The team is left with no clear understanding of how to identify which accounts should be automatically processed versus which require manual pulling. ### Critical Security Incident and Credential Management A severe security incident was disclosed where internal login credentials for a master account containing *all* Constellation customer data were emailed to an external party. This account must be immediately secured. The priority is two-fold: first, to ensure these high-risk credentials are completely removed from any system where they could be synchronized or exposed (specifically UBM), and second, to change the account password. The incident elevates the issue from a potential internal vulnerability to an active data breach risk with serious legal and regulatory implications if the credentials are misused. ### Process Gaps for New Customer Accounts Beyond fixing the broken automation for existing accounts, the team identified a major procedural gap: there is no established process to enroll *new* Constellation customer accounts for automatic invoice downloading. This gap means that as the company onboards new clients, their invoices are likely to fall through the cracks from the start, perpetuating the manual work problem. The lack of a handoff process to the operations team (Galo) for new accounts is a systemic failure that needs to be addressed to prevent future backlogs. ### Temporary Manual Solutions and Next Steps To mitigate the immediate business impact, especially for the at-risk Park Ohio account, the team proposed a temporary manual workaround. This involves having the BDE team manually pull Constellation invoices on a daily basis to prevent late payments. However, this is explicitly viewed as a stopgap measure. The long-term solution requires coordinated action: consulting with Mary upon her return for insights from a previous operations meeting, determining the feasibility of restarting or replacing the old automated system, and establishing a robust, documented process for both existing and new customer accounts to eliminate manual dependency and secure sensitive data.

## Summary The meeting centered on evaluating two core strategic options for a database migration project, with a particular focus on security exceptions, customer impact, and the required timeline for implementation. ### Core Dilemma: Database Placement and Access Model A fundamental decision point was identified between two paths for the ongoing migration. The first option involves proceeding with the current plan to place the database in the "red" environment while carrying forward security exceptions for direct customer access. The second, and more complex option, entails removing those exceptions by moving the database to the more secure "green" environment and implementing an API layer for all customer data access, which would necessitate changes on the customer side as well. ### Evaluating the "Green" Option with API Implementation The primary uncertainty requiring assessment was the effort and timeline impact of shifting to a full API-based model. It was clarified that simply moving the database to green is technically straightforward, but the significant work lies in building the necessary APIs to replace direct database access. This shift would enable external customers to run their custom reports and access filtered data through these APIs instead of directly querying database views. ### Security and Timeline Implications Maintaining the current plan with security exceptions raised concerns, particularly with leadership, as an August timeline that still carried these exceptions was seen as surprising and potentially unacceptable. The discussion highlighted the need to fully articulate the risks and trade-offs of both options to secure a definitive strategic direction from senior leadership. ### Parallel Development and Path Dependency An intermediate suggestion was made to allow certain development tasks to proceed in parallel within the red environment, as they are not data-dependent. This approach was proposed to maintain momentum while the broader strategic decision is being resolved, suggesting that some work could continue regardless of the final chosen path for database access. ### Required Leadership Decision and Communication A strong consensus emerged that the team must prepare a clear articulation of both options-including the remediation activities, effort, and timeline implications of removing the database exposure exception-for senior leadership. The decision was deemed significant enough to require explicit direction from key leaders before the project can move forward confidently, framing it as a key strategic decision for the program.

## **Summary** The meeting centered on critical operational challenges within a bill payment or invoice processing system, primarily focusing on persistent data quality issues, customer-specific problems, and overwhelming workload management. The conversation revealed a system under significant strain, with urgent fixes needed to prevent customer escalations and ensure accurate financial reporting. Key pain points included fundamentally broken data for certain utilities, an epidemic of duplicate invoices, and specific high-risk accounts requiring immediate intervention. ### **Critical Data Integrity Failures: Propane Billing** The system's handling of propane (erroneously referred to as natural gas) billing is fundamentally broken, corrupting all related reporting. This failure stems from inconsistent vendor measurements and flawed unit conversions. - **Core Breakdown:** The process for capturing and converting propane usage data is defective. Vendors use different definitions for measurement units (e.g., "cylinder"), and the system's single, standardized conversion to gallons is incorrect, making the data unusable for analysis. - **Impact on Reporting:** This error is not minor; it "messes up the entire reporting" for these bills. The analysis generated from this flawed data is deemed not useful for customers, indicating a severe quality issue that undermines the service's value proposition. ### **Epidemic of Duplicate Invoices** A significant portion of daily operations is consumed by identifying and deleting duplicate bills, which is rampant and worsening. - **Volume and Impact:** Estimates suggest at least 10% of daily invoices are duplicates, with thousands of bills being deleted over a three-month period. This creates massive inefficiency, as team members spend considerable time manually identifying and removing these duplicates instead of performing value-added work. - **Root Causes:** Several factors contribute to this problem. A primary issue is incorrect account number matching during invoice ingestion, which prevents the system from automatically flagging duplicates. Other sources include receiving both paper and electronic (portal) copies for the same service, and potential issues with download processes or customers emailing invoices redundantly. - **System Limitations:** Current duplicate detection logic is insufficient. It relies on exact matches of vendor, customer, amount, and service dates, or pixel-perfect PDF comparison, which fails for scanned versus downloaded documents or bills where the invoice date changes upon download. ### **High-Risk Customer Accounts and Escalations** Specific customers, notably Jacob and Victra, are at a crisis point, with systemic neglect threatening major business relationships. - **Jacob Account in Peril:** The Jacob account is described as a looming "nightmare," receiving no dedicated attention. Their services are being "shut off daily," and the account is a priority due to the imminent risk of a severe customer escalation, similar to past issues with Victra. - **Victra's Ongoing Demands:** Victra remains a "never ending story," consuming enormous resources. The team is bracing for further complaints despite being current on payments, as past issues like emergency payments are now being questioned. A recent tense meeting highlighted customer frustration with internal presentation materials, indicating strained relations. - **Selective Intervention Strategy:** A strategy of isolating certain complaining customers (like Sheets) from automated fixing scripts is in place to avoid constant back-and-forth, while keeping a close manual watch on others known to be vocal (like Royal Farms). ### **Team Workload and Process Bottlenecks** The team is operating under extreme pressure, manually triaging a massive backlog of errors with insufficient resources. - **Manual Triage Overload:** The core activity involves reviewing hundreds of invoices line-by-line to correct errors, a process described as utterly blocking progress on system improvements. The sheer volume, such as 200+ new items daily for one customer (Extension), overwhelms capacity. - **Contractor Allocation:** Contractors have been strategically reassigned to focus solely on the high-volume Extension list to make a dent in the backlog, though this pulls them from other critical accounts. - **Internal and External Pressure:** The team faces "screaming" from customers and internal scrutiny regarding processing times and accrual reports, especially near the end of the fiscal year. There is a palpable fear of metrics being pulled to audit individual productivity. ### **Systemic Limitations and Uncontrollable Factors** The discussion acknowledged some issues that are inherent to vendor systems and likely unsolvable. - **Unfixable Vendor Quirks:** Certain problems, like some utility portals generating a new invoice date equal to the download date (while the due date remains static), are deemed uncontrollable system issues that the team must simply accept and work around. - **Portal Integration Gaps:** The inability to reliably turn off paper bills when a portal feed is active leads to duplicate ingestion. A known workaround (using a special placeholder number for deleted bills) is likely not being implemented for new customers, exacerbating the duplicate problem. - **Data Entry Dilemmas:** The process is hampered by complex, one-off scenarios that require manual intervention and judgment calls, such as invoices appearing under incorrect vendors or decisions on whether to process older, superseded bills.

## Summary The meeting was a detailed technical review of multiple utility billing data issues, focusing on discrepancies in consumption reporting, account mappings, and unit conversions. The primary goal was to audit and understand the root causes of errors flagged in various utility accounts, ranging from natural gas and water to propane and electricity. ### Duplicate Accounts and Data Mapping Issues Several accounts were identified with problematic data structures that led to reporting inaccuracies. A recurring issue was duplicate account entries and incorrect mappings between virtual accounts and physical locations, which caused consumption data to be split or misattributed. - **Duplicate Entries and Unlinked Bills:** For one natural gas account, bills prior to a specific date were not correctly linked, creating a mapping issue. While this did not immediately cause missing usage data (as consumption across virtual accounts still summed to the correct location total), it was noted as a problem requiring a fix to ensure accurate per-account reporting. - **Split Build Blocks Overlapping:** In some cases, a single virtual account contained multiple "build blocks" with overlapping service periods for the same type of charge (e.g., supply charges). This resulted in the system capturing the same data in two separate blocks, which could appear as a discrepancy to end-users reviewing the raw data, even though the total consumption for the location remained correct after aggregation. ### Incorrect Service Dates and Billing Periods A number of bills were found to have service dates that were clearly erroneous, directly impacting the accuracy of period-based reporting. - **Invalid Date Ranges:** Examples were reviewed where the service period on a bill was listed as spanning two months, which is impossible for a standard monthly bill. This was identified as a data ingestion error where the start date was incorrect. The fix required manually updating the start date within each affected build block to reflect the accurate, shorter billing cycle. ### Challenges with Propane Bill Conversions A significant portion of the discussion centered on the complexities of handling propane deliveries from different vendors, which use varied units of measurement that the current system cannot process accurately. - **Multiple Vendor Unit Definitions:** The core issue is that three different propane vendors each use distinct definitions for their delivery units (e.g., cylinders, pounds). The current system lacks the ability to apply multiple conversion rates for the same utility type (propane) to standardize these deliveries into a common unit like gallons. - **Proposed System Change:** A practical solution was proposed: adding support for "pounds" as a standardizable unit within the system. This change would require a software release but would allow for a single, vendor-specific conversion rate from pounds to gallons, simplifying the process compared to managing multiple gallon-conversion rules. This was highlighted as a necessary fix, though it requires coordination to implement. ### Discrepancies in Historical Bill Data The review uncovered several anomalies in historical utility data that had been manually generated or imported from client files. - **Imported Data Inconsistencies:** For certain accounts, historical bills were created by the data services team based on files received from the client (e.g., Hexpol). These bills sometimes contained oddities, such as energy charges without corresponding consumption data or usage values that appeared "way off." It was clarified that these were known historical entries and not representative of ongoing, current billing issues. - **Questions on "Converted" Bills:** Confusion arose around the term "converted bill" in one audit note. It was determined this likely referred to these historical bills and not to any real-time unit conversion process within the system, as no such conversion was being applied to the bills in question. ### Electricity Consumption and Charge Calculations The audit also covered specific electric bills to verify that consumption totals and peak/off-peak calculations were being captured correctly. - **Total Consumption Verification:** For one electricity account, the total consumption for the month was found by summing the on-peak, mid-peak, and off-peak usage values from the distribution section of the bill. The system's calculated total was confirmed to be accurate, even though the method of calculation (involving subtraction in some cases) was complex and not immediately intuitive from the bill's layout. - **Charge Accuracy:** In another instance, a complaint about "charges being off" was investigated. The discrepancy was traced to how the system presents data: certain line items like "past due amounts" are recorded at the overall bill level, not within individual build blocks. Therefore, while the total amount due was correct, a breakdown at the build block level would not include these items, creating a perceived mismatch. ### General Data Quality and Reporting Impacts Throughout the review, broader themes emerged regarding how data quirks affect end-user reports and the importance of correct data structuring. - **Impact of Duplicate Bills:** The handling of true duplicate bills (e.g., a re-issued bill with late fees) was discussed. The system flags these with a duplicate bill error, preventing the second instance from being processed into the monthly usage report, which is the correct behavior to avoid double-counting consumption. - **Understanding "Total Bulk" and Other Units:** Several bills contained ambiguous units of measure like "Total Bulk" or "EA" (likely "each"), which were not clearly defined and posed a challenge for accurate categorization and conversion. These were marked as items requiring domain expertise to clarify. - **Correct Values Despite Split Data:** A key takeaway was that many flagged issues-particularly multiple build blocks on a single account-do not negatively impact the final aggregated consumption totals reported to the client. The values are often correct; the irregularity lies in the underlying data structure.

## Propane Billing and Unit Conversion Issues A critical discrepancy was identified in how propane consumption is captured and calculated. The system currently records usage in "cylinders," but the underlying bills show the actual measurement in pounds. The core problem is that the application does not support pounds as a unit of measure for propane, only gallons, terms, and cylinders. - **Unsupported Unit of Measure:** Bills showing propane usage in pounds trigger an "unsupported unit" error because the system lacks a built-in conversion from pounds to gallons. - **Inconsistent Cylinder Definitions:** The existing conversion rate in the system assumes one cylinder equals approximately 4.014 gallons. However, this is problematic because cylinder sizes (e.g., 32 lbs vs. 33.5 lbs) vary between vendors, making a single conversion rate inaccurate. - **Significant Calculation Variance:** Using the system's cylinder-to-gallon conversion yields a calculated usage of roughly 16 gallons for a sample bill. In contrast, a direct pounds-to-gallons conversion (using a rate of 0.236 gallons per pound of propane) results in approximately 30 gallons-nearly double the amount. This major discrepancy must be resolved for audit accuracy. ## Natural Gas Bill Analysis and MCF Conversions Several natural gas bills were reviewed where auditors flagged potential issues, primarily stemming from unit of measure conversions that are performed automatically by the system. - **Automatic Conversion to Therms:** The system's default unit for natural gas is **therms**. When bills are captured in **MCF (thousand cubic feet)**, the system automatically converts the usage using a standard factor (e.g., 10.37 therm/MCF). This converted value is what appears in reports. - **Auditor Confusion:** The flagged "issues" often were not errors but misunderstandings. Auditors comparing the raw MCF value on the bill to the therm value in the system reports saw a mismatch, not realizing the conversion had taken place. Manual checks confirmed the underlying calculations were correct. - **Bill Structure Verification:** For bills containing both supply and distribution charges, it was confirmed that the consumption (usage) should typically match between the two segments, as the same volume of gas is being supplied and then delivered. This was validated in the reviewed bills. ## Bill Structure and Data Capture Problems The review uncovered inconsistencies in how complex bills are structured within the system, leading to potential reporting inaccuracies. - **Mislabeled Commodity Types:** A bill clearly containing water usage data was incorrectly labeled as "Lightning" in the system, based on a meter ID or source file error. This misclassification would cause the consumption and charges to appear in the wrong utility reports. - **Incorrect Build Block Types:** One natural gas bill was set as "distribution only" but contained a "supply" observation type within it. This bill should likely be classified as "full service" to accurately reflect its contents. - **Multiple Build Blocks on Single Bills:** Some bills were captured with multiple build blocks (e.g., Water, Stormwater, Cash Flow) as received from the source data feed. While all charges are captured, consumption metrics are only tied to the relevant commodity (e.g., Water), meaning stormwater charges would roll up into general water charge reports without separation. ## Data Inconsistencies and Review Process Underlying data inconsistencies and the approach to the audit review were discussed. - **Inconsistent Data Sources:** For some natural gas bills, different values from the same PDF (e.g., a "MCF Used" field vs. a "Monthly Usage" field) were captured in different months, leading to an inconsistent data series. It was unclear which value was the correct one to use. - **High Volume of Similar Issues:** The propane cylinder conversion issue and the natural gas MCF/therm clarification are not isolated incidents but affect a large number of bills for the client. - **Focus on False Positives:** The strategy for the audit review shifted toward identifying "false positives"-bills flagged by auditors that are, in fact, correct based on the system's designed conversions and capture logic-rather than attempting to re-engineer every bill. ## Path Forward for System Adjustments Potential solutions to the most pressing issue, the propane unit conversion, were explored. - **Proposed Hotfix:** A short-term solution was proposed to add **pounds** as a supported unit of measure for propane, along with a standardized pounds-to-gallons conversion factor. This would allow all existing bills captured in pounds to be repaired and calculated correctly without the unsupported unit error. - **Challenge of Accurate Conversion:** Implementing this fix is contingent on determining a reliable, standardized conversion factor from pounds to gallons for propane, acknowledging that this conversion can vary slightly based on temperature and pressure. - **Limitation of Current Logic:** The system cannot currently accommodate customer-specific or vendor-specific conversion rates (e.g., for different cylinder sizes). A universal rate must be applied, which is a known limitation affecting precision.

## Summary ### Urgent Audit Preparation and Data Crisis The meeting centered on an urgent and critical data quality crisis for a customer facing an external audit by Ernst & Young. The audit, scheduled for the coming Monday, will scrutinize emissions data for fiscal years 2024 and 2025. The core problem is that the customer's utility bill data in the system is a "mess," with widespread inaccuracies in usage captures and bill classifications that threaten the audit's success and could have severe professional repercussions. - **Critical Timeline and Stakes:** The team is under immense pressure to rectify data before the audit. The customer is manually reviewing every single bill to identify errors, and the platform team must correct them. There is a palpable fear that the scale of inaccuracies could lead to significant consequences, including job losses for individuals involved. - **Root of the Problem:** The data issues are systemic and not new. They stem from historical problems with data ingestion and ongoing manual setup errors. The team acknowledges they have "no one else to blame" for the current state, as the platform is now fully responsible for the data's accuracy. This situation is seen as a potential risk for any customer undergoing a similar audit. ### Systemic Data and Process Issues The discussion revealed deep-seated problems with how utility data is captured, classified, and reported within the platform. The issues prevent accurate emissions reporting and undermine customer trust. - **Incorrect Usage and Classification:** A primary issue is the misclassification of vendor types (e.g., Full Service vs. Distribution/Supply) and incorrect assignment of observation types (service descriptions) for line items like "use" or "use cost." If these are wrong, usage data does not flow correctly into calculated values and, consequently, into the final audit reports. - **Platform Reporting Gaps:** There is a concerning disconnect between what the data processing system (DSS) captures and what is visible and usable in the front-end platform (UBM). The team lacks a straightforward way to map a bill's internal ID to its corresponding record in the data processing system, making holistic analysis and troubleshooting difficult. - **Lack of Proactive Monitoring:** The team admits to having no effective way to gauge the severity or scope of the problem proactively. They are consistently surprised by the magnitude of inaccuracies when a crisis like an audit arises, indicating a lack of ongoing data quality assurance. ### Strategy for Manual Review and Validation Given the time constraints and systemic issues, the team formulated a strategy for a massive manual review of bills to identify and correct errors before the audit. - **Prioritization by Impact:** The plan is to focus on the customer's 18 locations, prioritizing those with the highest utility usage volumes. The goal is to create a "heat map" of the most critical sites and months to maximize the impact of limited review time. - **Manual Verification Process:** The review involves manually checking each bill's PDF against its digital record in the platform. The reviewer must validate two key elements: the correct vendor type (based on utility and deregulation rules) and the accurate capture of usage, ensuring it is not double-counted due to incorrect observation types. - **Comparative Analysis:** A parallel approach involves extracting all usage data from the data processing system (DSS) to create a pivot table showing total usage by utility type and site. This high-level view can be compared against the platform's numbers and the raw bills to quickly identify major outliers and discrepancies. ### Key Learnings from Expert Training A significant portion of the meeting was dedicated to a training session with an operations expert to understand the rules for correctly validating and classifying bills, which are riddled with exceptions. - **Vendor Type Rules:** The determination of "Full Service" vs. "Distribution/Supply" depends on the utility type and state deregulation status. Generally, electricity and natural gas in deregulated states are split, while propane, water, and sewer are almost always Full Service. Bills from landlords or for reimbursements often complicate these rules and may require pragmatic exceptions. - **Avoiding Double-Counting Usage:** A critical lesson was identifying "counted usages." Line items labeled **"use"** or **"use cost"** are counted in totals. If a bill has both a total "use" line and detailed line items also labeled as "use," the usage will be double-counted. The correct approach is to capture the total usage only once, with other line items marked as non-counted variants like "adjustment use cost." - **Unit of Measure Challenges:** Correctly interpreting the unit of measure on bills is a common hurdle, with examples like propane billed in "cylinders" requiring conversion to a standard weight (pounds) based on vendor-specific information. - **Build Block Structure:** Bills should not have separate build blocks for singular charges like late fees or taxes. These should be consolidated into the main build block for the relevant commodity (e.g., gas tax added to the gas build block). Creating extra blocks causes overpayment and reporting inaccuracies. ### Next Steps and Long-Term Concerns The meeting concluded with a plan for immediate action and reflection on the broader, unsustainable nature of the current process. - **Immediate Action Plan:** The immediate focus is on executing the manual review through the night and next day, tackling as many high-priority bills as possible. A follow-up meeting with the customer is scheduled to discuss findings and the path forward for the audit. - **Acknowledging Incomplete Solutions:** The team is pessimistic about having a complete, pristine data set by the audit deadline. The goal is to gain a better understanding of the problem's scope and provide a defensible, if imperfect, data story to the auditors. - **Recurring Problem with No Systemic Fix:** A major concern is the lack of a long-term, scalable solution. The current approach of manual review and correction is not sustainable. Every customer undergoing an audit is likely to face similar issues, revealing a fundamental weakness in the platform's data integrity and validation processes. The team expressed frustration at the repeated cycle of discovering massive data problems only during high-pressure crises.

## Prospect The prospect represents a traditional energy company, Constellation, which is embarking on a significant digital transformation initiative. While their core business is power and gas, they are now building internal software capabilities and are in the process of evaluating and consolidating their technology stack. The individual involved is focused on establishing a centralized, standardized API management platform to govern and synchronize multiple disparate applications currently developed in silos. Their background indicates a need to move from a fragmented, ad-hoc software development model to a governed, enterprise-ready platform that can support both current API needs and future AI-driven use cases. ## Company Constellation is a power and gas company with historically limited in-house software development experience. The company is currently managing three separate applications hosted across different cloud providers: Google Cloud Platform, Microsoft Azure, and Amazon Web Services. Each application has its own independent development team, roadmap, and deployment environment, leading to a lack of standardization and governance. To address this, the company is actively developing "Navigator," a strategic, centralized platform aimed at unifying API management, security, and developer workflows across the entire organization. This initiative is part of a broader effort to mature their software engineering practices over the next few years. ## Priorities The company's key priorities for the API management platform are comprehensive and driven by both immediate consolidation needs and future strategic goals: - **Centralized Governance & Standardization:** A primary objective is to bring the three siloed applications under a single management plane. This includes establishing consistent security policies, access controls, and deployment workflows across all teams and cloud environments. - **Security and Compliance:** Implementing robust authentication and authorization is critical. This includes support for various identity providers (IdPs), role-based access control (RBAC) for both internal developers and external customers, and meeting compliance requirements such as SOC 2 and NIST standards. - **Full Lifecycle API Management:** The platform must support the entire API lifecycle-from design and development to publishing, versioning, and retirement. This necessitates a developer portal for API discovery and documentation, both for internal teams and external consumers. - **Advanced Traffic Management and Reliability:** Requirements include sophisticated rate limiting, throttling, and service protection mechanisms to safeguard backend services from abuse and ensure reliability for critical consumers. Support for various load-balancing algorithms is also noted. - **Observability and Analytics:** Gaining deep visibility into API usage, performance, and errors is essential. This involves built-in analytics dashboards, the ability to create custom reports, and integration capabilities with external monitoring tools like Datadog or Splunk. - **Monetization Capabilities:** There is a clear need to productize APIs and enable monetization. This includes defining API products with feature-based plans, metering usage, and integrating with billing systems like Stripe to handle invoicing and overage charges. - **Support for AI and Agentic Workflows:** Forward-looking priorities include preparing for AI integration, specifically managing traffic for large language models (LLMs) and supporting the Model Context Protocol (MCP). This encompasses capabilities like semantic caching to control costs and providing governance for AI agent interactions. - **Operational Flexibility and Performance:** The solution must offer deployment flexibility, including hybrid models where the data planes reside within the company's own cloud VPCs for security. It must also deliver high performance, scalability, and low latency, capable of handling significant transaction volumes. - **Accelerated Timeline:** There is an ambitious goal to have at least two of the three applications running on the new platform and be production-ready by the first quarter of the next calendar year.

## Summary ### The Urgent Situation and High-Stakes Audit A critical data accuracy crisis has emerged, requiring immediate triage to prepare for a high-stakes, third-party audit by Ernst & Young scheduled for the upcoming Monday. The audit covers all 2025 data for a wide range of commodities, including natural gas and propane, encompassing usage, cost, and emissions reporting. The gravity of the situation is severe, as inaccurate data could lead to significant professional, legal, and financial repercussions, including job loss and lawsuits. The entire team has canceled other meetings to dedicate full focus to resolving these discrepancies before the deadline. ### Discovery of Widespread Data Discrepancies An intensive manual review of 2025 invoices has uncovered widespread and inconsistent inaccuracies across multiple commodity types, far exceeding initial expectations. A dedicated team has been comparing every invoice against the system data to flag mismatches in usage or cost. - **Propane Data is Systemically Incorrect:** The propane data is particularly problematic, where most entries are showing only half of the actual usage. This stems from an incorrect or inconsistently applied conversion formula for 33-pound cylinders (7.78 gallons per cylinder), affecting the accuracy of both usage and downstream emissions calculations. - **Errors are Random and Inconsistent:** The inaccuracies are not uniform; they appear randomly across accounts and invoices, making them difficult to predict and correct without a line-by-line review. - **Scope Extends Beyond Initial Findings:** While initial concerns were around natural gas, the review has expanded to reveal issues with "propane and other areas," indicating a broader data integrity problem. ### Identification of Root Causes The investigation points to two primary, concurrent root causes for the erroneous data, one related to system configuration and the other to data entry processes. - **Incorrect Account Setup:** A significant issue originated in April when certain service locations were configured with the wrong "service type" during their initial setup. This single configuration error has caused all subsequent data for those locations to be reported incorrectly for the entire year, but fixing the root setup will propagate corrections forward. - **Faulty Data Entry and AI Processing:** Inaccuracies have also been introduced through manual data entry errors. Furthermore, the Artificial Intelligence (AI) tool used to extract data from invoice PDFs has been pulling incorrect fields inconsistently, sometimes interpreting the same bill differently on separate occasions, which compromises reliability. ### Triage Strategy and Collaborative Effort The team is executing a coordinated, short-term fix to cleanse the 2025 data for the audit, while acknowledging the need for long-term system improvements. - **Prioritizing a Practical, Rapid Fix:** The immediate goal is to produce accurate *annual* totals for 2025 to satisfy the auditor. A pragmatic approach is to correct a representative month, establish a correction "delta," and apply it to the year, rather than perfectly rectifying every single monthly entry under extreme time pressure. - **Division of Labor for Efficiency:** Work is divided between teams: one group is exhaustively auditing invoices to create a definitive list of erroneous Bill IDs, while the technical team uses that list to implement fixes in the system. The intent is to front-load corrections, with completed audit lists being handed off for repair as soon as possible during the day. - **Verification and Communication Plan:** A short checkpoint meeting is tentatively scheduled for 2:30 PM Eastern the following day. The preference is to cancel this meeting via email confirmation once all fixes are verified, signaling that the data is ready for the final audit report compilation. ### Path to Resolution and Future Safeguards The plan outlines clear steps for immediate remediation and introduces controls to prevent recurrence, addressing concerns about being an untested environment for new technology. - **Immediate Correction Protocol:** Corrections will be made directly to individual bills based on the audit list. System configuration errors for specific accounts will be corrected at the source, which will automatically rectify all associated data. The fixes are reported to reflect in the system in real-time, without requiring an overnight refresh. - **Implementing Long-Term Data Integrity Measures:** For the future, two key safeguards are planned: the implementation of dual data validation checks to replace manual entry, and an enhanced AI review layer that flags discrepancies between the OCR output and the manually entered data for human verification. - **Demand for Mature Technology Deployment:** A strong expectation was set that new features, particularly AI-driven data extraction, must undergo rigorous quality assurance and stability testing before being deployed in a live, production environment used for critical financial and compliance reporting. There is a firm refusal to continue as a testing ground for experimental technology.

## Summary The meeting centered on planning and executing a large-scale utility account migration project for the client Simon, involving 8,823 accounts. The team is under significant time pressure, with a target Go-Live date of March 31, but faces major hurdles due to delayed project initiation and dependencies on third-party notifications. ### Project Scope and Current Status **The project involves migrating a massive number of accounts with a compressed timeline, creating an immediate need for detailed planning and resource allocation.** The total account list provided by Simon is 8,823, which is higher than the initially expected ~7,800. - **EDI vs. Non-EDI Breakdown:** Within the total, 2,457 accounts were originally flagged as potentially using EDI (Electronic Data Interchange). Initial processing has isolated 848 confirmed EDI accounts that lack standard invoice image links. - **Work Completed:** A script has been run on the remaining 7,412 accounts to separate non-EDI bills for processing. So far, 10 test bills have been successfully mapped and processed in the platform as a proof of concept. - **Timeline Pressure:** The contract was signed in July, but substantive work did not begin until November, putting the project behind schedule from the outset. ### Critical Path: Portal Setup and NG Notification **The single biggest constraint on the project timeline is the inability to begin setting up vendor portals until formal notice is given to the incumbent provider, NG.** - **Notice Period Uncertainty:** The team must clarify the contractual notice period with Simon's leadership, as there is confusion over whether it is 30, 60, or 90 days. A longer period is critical for feasibility. - **Portal Setup Volume:** The team must complete portal setups and change of address (COA) processes for all 8,823 accounts. The work cannot begin in earnest until NG is notified, which will severely compress the active execution window leading up to the March 31 Go-Live. - **EDI Account Strategy:** A subset of ~300 accounts are with Constellation and can be accessed via their CDP portal independently, which is a minor relief. However, all other EDI accounts will require portal setup and manual bill downloads once credentials are available. ### Resource Planning and Process Refinement **Given the scale of the project, there is a pressing need to optimize resources and learn from past implementation challenges to avoid repeating mistakes.** - **Resource Allocation:** Currently, only one team member (Alberto) is manually processing PDFs for data extraction, mapping, and UBM setup. A formal plan for additional resources from late January through March is required. - **Vendor Requirement Database:** A major inefficiency identified from past projects is the lack of a centralized database detailing specific setup requirements for each utility vendor (e.g., unique LOA forms, notarization needs, required data fields like Tax ID or last bill amount). This leads to a reactive, unprofessional appearance with clients. - **Immediate Action:** The team will hold a working session to populate a detailed spreadsheet for the top vendors, documenting known requirements (utility vs. client LOA, needed documents, etc.) based on lessons learned from previous clients like Ascension and Vector. ### Data Processing and System Configuration **Efficient data handling and upfront configuration are essential to avoid costly rework later in the project lifecycle.** - **Upfront Attribute Gathering:** It was emphasized that gathering all location attributes and General Ledger (GL) splits *before* mapping and processing bills is far more efficient. Doing this work later forces the team to touch each account multiple times. - **AP File Format:** The accounts payable (AP) file format for Simon will be a custom configuration, not a standard template. - **GL Strategy:** The plan is to mirror the GL allocation currently used in NG's system to simplify the transition. ### Next Steps and Client Communication **The immediate focus is on internal alignment to build a credible execution plan before Simon can proceed with notifying NG.** - **Internal Working Session:** A dedicated call will be scheduled for the operations team to detail vendor requirements for the top utilities, forming the basis of a realistic project plan. - **Client Timeline Review:** The visual timeline shared with Simon shows key milestones, with data extraction and portal setup as the longest phases. The next critical step is aligning internally and then informing Simon when they are comfortable to issue the notice to NG, which will trigger the portal setup phase. - **Upcoming Discussion:** A meeting with Simon's AP team is scheduled for the following Tuesday to review the test bills and discuss the implementation further.

## Summary ### Issues with the Current Build System and the Concept of a Build Template The meeting centered on identifying and addressing fundamental flaws in the current legacy system's approach to handling "builds." The core problem is the absence of a properly utilized "build template," which is leading to multiple systemic issues. The current method is causing inaccuracies and inefficiencies in data capture and processing. - **Lack of Setup and Standardization**: The system lacks a mechanism to correctly set up builds within DSS (Data Submission System), which is a critical gap that needs to be addressed. - **Incorrect Logic Application**: Presently, specific logic (e.g., for determining observation types or usage charges) is being hard-coded or applied in an ad-hoc manner. This logic often already exists within the build template for a given account, so re-implementing it is redundant and error-prone. - **Inconsistent Data Entry**: In DSS, fields that should be constrained (like usage types) are currently freeform, leading to incorrect data entry and making it difficult for operators to correct errors. This creates a frustrating and inefficient audit experience. ### The Proposed Solution: Integrating the Build Template into DSS The primary solution discussed is to systematically incorporate the existing build template into the DSS workflow. This integration would act as a crucial safeguard, ensuring data integrity and streamlining operations by leveraging predefined rules. - **Template as a Single Source of Truth**: The build template, which is tied to a unique combination of customer, vendor, and account number, should dictate what data fields are applicable and what logic should be followed during data capture in DSS. This would eliminate guesswork and hard-coded rules. - **Cross-Platform Consistency**: While the immediate focus is DSS, the build template is envisioned as a shared resource that should be consistent across DDS, DSS, and UVM systems to maintain data coherence throughout the platform. - **Future-Proofing for Setup Builds**: Incorporating the template is also a preparatory step for a future where setup bills could be created directly within DSS, making the process more comprehensive and controlled. ### Determining Build Types: A Case Study in Flawed Logic A concrete example was examined to illustrate the problems with the current logic. The discussion focused on how the system determines a build's type (e.g., full service, distribution, or supply) and the downstream errors this causes. - **Current Flawed Methodology**: The system currently determines build type based on the service type listed on a bill, which can be incorrect or misleading, especially since a single bill can contain both distribution and supply components. - **The Correct Approach**: The build type should be definitively known and defined within the account's build template from the initial setup. Relying on the template would prevent misclassification. - **Example - Natural Gas Charges**: The logic that "wellhead use" is always applied for natural gas is incorrect. This should only apply if the build template specifies a *supply* or *distribution* type. Using the template would automatically enforce this correct rule. ### Addressing the DSS Audit Queue and Data Routing The conversation shifted to immediate, tactical issues regarding bills stuck in the DSS audit queue and how to route them for resolution effectively. - **Clearing the Audit Backlog**: There is a need to manually push invoices currently stuck in the DSS audit status over to the Data Audit system for operator review, similar to a process executed the previous week. - **Including Critical Error Context**: When routing these items to Data Audit, it is essential to include the specific error message or observation details in the operator notes field. This provides crucial context for the audit team to understand and fix the issue quickly, as this error information is not currently being passed through automatically. - **Scripting the Solution**: A script will be adjusted to facilitate this data move. While a more permanent, automated integration is the ideal long-term solution, the immediate fix involves updating the script to include the error details in the transfer. ### Next Steps and Implementation Planning The meeting concluded with a plan for executing the discussed strategies, balancing immediate fixes with longer-term architectural improvements. - **Immediate Action on Audits**: The first action is to run a script to transfer DSS audit items to Data Audit, ensuring all relevant error information is included in the operator notes for effective resolution. - **Investigating Template Integration**: Following the audit cleanup, the next major task is to investigate how to pull the build template data from DDS and integrate it as a safeguard within the DSS data capture process. This requires understanding the technical access and methods for retrieving this template information. - **Preparatory Work for Reporting**: Work will begin on creating a report template. Once the template is designed, the development team can proceed with its implementation to improve visibility and tracking.

## Summary ### Initial Technical Review of Data Batches The meeting opened with an immediate technical review concerning the visibility and count of items within data batches, revealing a discrepancy in displayed totals. - **Resolving Data Display Issues:** A primary issue was identified where the interface appeared to show only a limited number of items (e.g., 30). The resolution involved manually scrolling to the bottom of the list, which then displayed the full count, revealing batches of 50, 40, and 15 items. - **Verification of Batch Counts:** There was a specific focus on verifying the exact number of items in the batches, with initial counts of 17 or 16 items noted before confirming the final numbers through the scrolling action. ### Transition to Core Development Agenda Following the resolution of the immediate data view issue, the discussion intentionally pivoted to the central, planned topic for the session. - **Focusing on Systematic Problem-Solving:** A deliberate decision was made to shift focus onto tackling project challenges sequentially, one at a time, indicating a structured approach to development priorities. - **Introduction of the Build Template Topic:** The main objective of the meeting was introduced: to discuss and define the specifications or requirements for a "build template," which is evidently a key upcoming development task. ### Planning for Knowledge Transfer and Reference Significant emphasis was placed on documenting the forthcoming discussion for practical implementation and future reference. - **Intent to Record for Developer Reference:** Explicit plans were made to record the detailed conversation about the build template. The intent is to provide a clear, actionable reference for the developer tasked with working on it, underscoring the importance of accurate knowledge transfer. - **Technical Coordination for Recording:** A brief logistical exchange occurred to establish the method of recording the call, confirming that the technical setup was a necessary precursor to diving into the substantive build template discussion.

## Summary The meeting primarily focused on addressing critical data quality issues within a utility bill management system, particularly concerning natural gas consumption reporting for specific client locations. This led to a broader discussion about systemic improvements needed to prevent such issues in the future and the integration of different data platforms. ### Initial Project Context and API Considerations The conversation began by acknowledging ongoing Q1 planning and several technical challenges, including API development and defining a central source of truth for data, which set the stage for the deeper data quality discussion. - **Legacy System Issues and API Integration:** Concerns were raised about outdated data and inconsistencies between systems, specifically questioning the "central source" for bill data and the relevance of virtual accounts in a new "bill pay world." - **Resource Allocation for Technical Debt:** There was a strategic discussion about leveraging developer resources from a migration project to help with broader system-wide improvements, including "interpreter" issues on the Data Services (DSS) side. The goal is to have new team members solve problems others are already learning, rather than spreading existing teams too thin. ### Addressing Immediate Data Formatting and Reporting Issues The core of the meeting involved troubleshooting immediate problems with generating accurate client reports, highlighting a disconnect between data extraction and reporting formats. - **Report Generation Challenges:** A specific task involved updating a custom report with new data, but a formatting mismatch was encountered. The exported data file contained two extra hidden columns ("C site" and "year") not present in the destination report template, making a simple copy-paste operation impossible and requiring manual, cherry-picked data transfer. - **Action Plan for Data Verification:** The immediate plan was to update the report data back to January to ensure historical accuracy. A key step is to compare the newly populated report data against the "raw" data source to validate consistency before client delivery. ### Investigating and Remediating Data Quality Problems Significant time was spent diagnosing the root cause of incorrect data appearing in client-facing reports, tracing it back to source system configuration errors. - **Root Cause - Incorrect Observation Types:** The primary issue was identified as misconfigured "observation types" or "service descriptions" for certain natural gas bills. For example, a "Wellhead" job type was incorrectly assigned instead of the correct "Use" type, which caused consumption and cost data to be hidden or reported as zero in the monthly views. - **Impact and Validation of Fixes:** Correcting the observation type at the source immediately fixed the data displayed in the internal platform (UBM), confirming the diagnosis was accurate. This served as validation that the correction pathway was correct. - **Need for Operational Audit:** To fully resolve the issue, an operational (Ops) team review is required. They must audit all bills for the three affected locations to ensure the "observation type" aligns correctly with the "vendor type" for each account, a manual but necessary cleanup step for historical data. ### Resolving Ambiguous Unit of Measure Data A secondary but important data integrity issue was discussed regarding missing unit of measure information on bills, which complicates validation. - **Missing Bill Information:** For some bills, the unit of measure (e.g., therm) is not explicitly stated on the bill PDF, forcing the use of an educated guess. This creates a risk if a client were to question the basis of the calculations. - **Proposed Internal Solution:** To mitigate this, an internal reference spreadsheet was proposed. This would be maintained by the data services or Ops team, containing known or negotiated rates (dollars per therm) for clients, allowing for reasonableness checks and more confident data handling even when source documents are incomplete. - **Communication Strategy:** It was advised to avoid highlighting this particular unit-of-measure ambiguity in client communications for now, as no systematic change had been made. The focus should remain on fixing the observable data issues. ### Long-Term Systemic Solutions and Integration The meeting concluded with a forward-looking dialogue on preventing these issues through better system architecture and data flow between platforms. - **The Core Gap: Missing "Bill Template" Data:** A fundamental flaw was identified: the Data Services (DSS) interpreter system currently processes each bill in isolation without knowledge of the account's intended configuration or "bill template" (e.g., correct service type, observation type). This lack of context is why it perpetuates incorrect data if the source is wrong. - **Immediate and Long-Term Integration Plans:** The immediate priority is to extract the "bill setup" logic from the legacy system and incorporate it into DSS to serve as a reference template. The long-term vision is to create a single, shared "bill template" per account that is authoritative for both the DSS and UBM platforms, ensuring consistency. - **Architectural Debate on System of Record:** A key discussion point was whether UBM or DSS should be the ultimate source of truth for the bill template. The consensus leaned towards building the robust template logic within DSS first, as it is the data ingestion layer, and then integrating it with UBM to ensure operational changes in UBM are reflected back to DSS, closing the loop.

## Summary The meeting centered on critical operational challenges in billing, data processing, and client audits. Discussions revealed deep concerns about temporary fixes, systemic data accuracy problems, and the strain of managing high-volume client accounts. ### Challenges with Billing Adjustments and Past-Due Processing A core discussion revolved around the methodology for handling billing adjustments, specifically for older accounts (2015-2016). There is significant apprehension about continuing a particular adjustment process as a long-term solution. - **Questioning a Temporary Fix:** The current method of inserting adjustment lines to reconcile totals is viewed as unsustainable without addressing the underlying root cause of the discrepancies. The concern is that this approach is creating more data cleanup work for the future. - **Accuracy Issues Discovered:** The adjustment logic has been found to be flawed in certain scenarios, particularly when past-due amounts are involved. The **total amount due** captured by the system is sometimes incorrect, which in turn makes the automated adjustment amount invalid. - **Suspected Root Cause:** A potential cause identified is the *order of operations* in the system. If a past-due amount is removed first, it may cause the system to recalculate other figures (like current charges), leading to a mismatch with the initially captured data. This highlights a need to review whether checks should be against the *subtotal* versus the *total*. ### Audit Process and Reporting Struggles The team navigated a difficult audit process, highlighting gaps in preparation and the pressure to provide compliant documentation under tight constraints. - **Creative Compliance for an Audit:** To satisfy an auditor's request to demonstrate that 24 specific accounts were not missing, a non-standard report modification was made. A simple "yes/no" column was added to an onboarding sheet as a last-resort solution to meet the demand for documented evidence. - **Frustration with Audit Methodology:** While the audit uncovered some legitimate reporting oddities that required investigation, much of the process was considered inefficient. Auditors focused on a high number of already-deleted bills and made selections that seemed nonsensical, such as an account that had already been resolved. - **Underlying Data Problems:** The audit underscored a larger issue: a significant number of accounts (reportedly over 100) are not present in the platform but were not flagged by the auditors, who only identified 24. This points to a major data integrity gap that the team is aware of but was not required to fully address in this audit cycle. ### Systemic Issues in Data Processing and LLM Training Technical limitations of the current data processing framework and AI models were a major point of concern, directly impacting data quality and report accuracy. - **Observation Type Mismatches:** A critical error was identified where the **observation types** (e.g., full service, supply, distribution) on bills were incorrectly mapped because the system was not referencing the correct source data from the setup bill. This misclassification has caused widespread inaccuracies in reports for bills processed from March through August. - **Limitations of the LLM Workflow:** The practice of providing all processing instructions to the Language Learning Model (LLM) in a single file is degrading its performance. The more instructions added for edge cases, the lower the overall accuracy becomes. The solution proposed is to separate instructions by **bill type**, though this is acknowledged as a time-consuming change. - **Legacy of Manual Errors:** The problem is compounded because many of the foundational bills were entered manually. Subsequent automated (DSS) processes then propagated the same incorrect logic, cementing the errors into the system. ### Managing High-Volume Client Accounts The operational burden of processing daily invoices for large clients is creating resource allocation challenges. - **Overwhelming Daily Volume:** Accounts like Ascension are receiving over 200 invoices per day, requiring dedicated contractor resources solely to keep pace. This volume is so high that even with focused effort, it is difficult to clear the daily intake. - **Impact on Other Work:** The constant high-volume work for these key accounts ties up personnel, making it challenging to address issues for other clients or work on systemic improvements. The Medline account was cited as an example where the issue isn't complexity, but rather the constant shifting of human resources away from it to other priorities. ### Rebuilding Client Trust in Upcoming Reviews The team prepared for sensitive client meetings aimed at addressing billing errors and restoring confidence in their processes. - **Addressing Specific Billing Errors:** An imminent meeting was scheduled to review specific bills where miscaptures and incorrect unit measures led to inaccurate client reports. The goal is to clean up the data for a few key locations and, more importantly, use the session to **rebuild trust** with the client. - **Combating the "AI Error" Narrative:** There is ongoing frustration that clients often blame errors on AI when, in many reviewed cases, the mistakes were traceable to human actions or process gaps (e.g., a human-driven double charge). The team is actively working to correct this perception by providing clear evidence of root causes. - **Broader Control Concerns:** These repeated incidents lead clients to question whether adequate controls are in place to prevent billing errors. The team must continually demonstrate that they understand the failures and are implementing systematic fixes, not just one-time corrections.

## **Summary** The meeting centered on resolving critical data discrepancies in a utility billing system, specifically concerning natural gas usage reports generated for a partner. The core issue was that certain consumption data was not being correctly captured in monthly reports, leading to potential billing inaccuracies. The discussion involved a deep technical dive into system configurations, data mapping, and a live troubleshooting session to identify and correct the root causes. ### **Verification of Data for Monthly Billing Reports** The primary goal was to confirm that corrected data was ready for the monthly billing process run by an external team. A review had been conducted on problematic data for three specific locations. The consensus was that once internal data verification was complete, the external team could proceed with generating the report. However, a cautious approach was emphasized, seeking confirmation that the underlying data issues had been genuinely resolved before finalizing the billing run. The complexity stemmed from the data not being a simple dump but involving manipulation of fields like location description and vendor bill ID. ### **Technical Demonstration and Data Alignment** A screen share was initiated to compare the structure of the source report from the external partner with the internal system's data format. Key findings included: - **Column mismatch:** The external report contained additional columns (e.g., Calendar Month, Billing ID, Virtual Account) not present in the internal data view. - **Data insertion method:** It was determined that the process involved manually inserting new monthly data above existing rows in a spreadsheet, rather than a full refresh, which required careful handling to maintain data integrity. - **Resolution approach:** The immediate plan was to manually align the data by copying corrected figures (specifically from April) into the appropriate spreadsheet tabs, though this was acknowledged as a temporary, time-consuming fix. ### **Understanding Consumption Calculations and Service Types** The group analyzed why specific natural gas bills showed zero or incorrect total consumption in reports. The investigation revealed a fundamental misalignment between the service type and the observation code used: - **The core problem:** Bills marked with a "full service" vendor type were using observation codes designated for "supply-only" data (e.g., "wellhead" codes). This caused the system's calculation engine to assign the usage value to a "generation consumption" metric instead of the "total consumption" metric. - **Impact on reporting:** Consequently, the monthly usage report would show a zero or blank in the Total Consumption column, while the actual usage value sat in the Generation Consumption column. The partner's reporting logic, which uses the greater of the two consumption values, was failing because the correct data was in the wrong column. - **Diagnostic tools:** The "Monthly View" and "Calculated Values" tabs within the location details were highlighted as essential tools for diagnosing these issues. The "Calculated Values" section clearly shows whether an observation contributes to "total consumption" or "gen consumption." ### **Correcting Observation Types and Immediate Fix** A live edit was performed on a sample problematic bill to demonstrate the correction. - **The fix:** The service description/observation type on the bill was changed from "wellhead UC" (a supply-only code) to "use UC" (a code appropriate for full-service accounts that include both usage and charges). - **Immediate result:** After the change, the system's calculated values immediately updated, showing the usage correctly allocated to "total consumption." This change would then flow correctly into the monthly view and the generated reports. - **Scope of the issue:** The problem was identified as affecting multiple natural gas bills from a specific vendor (Constellation) across several locations. The immediate action item was to manually audit and correct the observation types for these known problematic bills. ### **Systemic Issues and Long-Term Solution** The meeting concluded by addressing the need for a permanent solution to prevent recurring errors. - **Root cause:** The error originates in the data ingestion pipeline (DSS/Data Services), where a "bill template" logic is incorrectly assigning "wellhead" observation codes to all natural gas bills, regardless of their actual service type (supply, distribution, or full service). - **Template disconnect:** There is a noted lack of synchronization between the validation rules and bill templates in the legacy Data Services system and the new UBM system. This gap allows incorrect data mappings to pass through without checks. - **Proposed future state:** A long-term solution requires updating the mapping logic in the data ingestion system to respect service type when assigning observation codes. Furthermore, there was a suggestion to eventually create a shared "bill template" mechanism between Data Services and UBM to ensure consistent rules and validations across both platforms, preventing similar systematic errors.

## Customer The customer is an energy or facilities management professional responsible for monitoring and reporting utility usage, specifically natural gas, across multiple locations for their organization. They operate in a complex environment with data sourced from multiple vendors (e.g., Constellation, another unspecified vendor) and rely on the product to process, convert, and report this data accurately for financial and operational oversight. ## Success The primary success with the product lies in its ability to centralize and process utility data from disparate vendors into a unified reporting system. This allows for the identification of significant anomalies, such as detecting instances of zero natural gas usage coupled with substantial financial payments, which are critical for catching billing errors or operational issues. The system's configuration to handle different units of measurement (like therms and MMBTU) and perform conversions is also a foundational strength that supports data integrity. ## Challenge The most significant challenge centers on data accuracy and validation processes, particularly when dealing with historical data imports and vendor-specific discrepancies. A specific issue was identified where natural gas usage data for certain locations from one vendor may have been imported with an incorrect unit of measure (MMBTU instead of therms), which directly impacts the accuracy of critical reports. Furthermore, there is a noted lack of automated, robust alerting within the product for "huge anomalies"-such as drastic, unexplained spikes in usage or cost between billing periods-which forces reliance on manual review to catch potentially costly errors. ## Goals The customer's key goals for using the product are: - To achieve complete and accurate population of all utility usage reports, ensuring all historical and current data is correct. - To verify and standardize the unit of measure for natural gas usage across all vendors and locations to guarantee report consistency. - To implement or enhance automated alerting thresholds within the product to proactively flag anomalous data patterns (e.g., zero usage with high cost, or massive month-over-month usage variances) without requiring manual data sweeps. - To efficiently audit and validate data for all utility locations, moving beyond a reactive approach to a systematic, ongoing verification process.

## Summary ### Customer Complaint Analysis The meeting centered on investigating customer complaints about incorrect data in embed reports, specifically focusing on discrepancies in natural gas bill details. - **Dyersburg location bill validation**: An April bill showed 7,589 MMBTU usage with a $29,119 charge captured as "wellhead use cost"-confirmed as correct for natural gas supply accounts. The customer's report displayed this data inaccurately despite correct system capture. - **Second location data discrepancy**: A bill with meter readings 27,599 and 27,600 showed a usage of "1" unit charged at $30, but validation revealed it should be **$0 usage** with only a base fee. The unit of measure (therms vs. MMBTU) was unresolved due to conflicting historical setups. - **Third location (KDL) issues**: Consumption data (e.g., 2571 vs. 275B) was mismatched between physical bills and reports, requiring manual verification of meter IDs and billing details. ### Data Capture and Unit of Measure Challenges Significant time was spent diagnosing why certain values were captured incorrectly across multiple accounts. - **Natural gas classification rules**: Confirmed that "wellhead use cost" applies exclusively to *supply* accounts, while "use cost" is correct for *distribution* accounts. - **Unit of measure conflicts**: Some accounts had dual units (therms and MMBTU) without clear vendor documentation, risking miscalculations. For example, a 1-unit usage charge was invalidated because it represented an unmetered base fee. - **DSS limitations**: The system fails to auto-classify bill types (supply/distribution/full service) accurately, often assigning opposite categories. ### Bill Template Management Discussion covered how bill templates are created, maintained, and matched to incoming bills. - **Template determination**: Bills are mapped to templates using the combination of client, vendor, and account number-with account numbers standardized by replacing special characters with dashes and removing spaces. - **Persistence of template errors**: Once line items are added to a template (via DSS or manual setup), they become permanent and can only be *inactivated* (not deleted), causing legacy data issues. - **New vendor challenges**: Templates for new vendors require manual setup since the system lacks auto-recognition capabilities. ### System Integration Gaps Attendees identified critical disconnects between data systems affecting accuracy. - **DSS-DDIS misalignment**: DSS doesn't ingest key account attributes (e.g., bill type) from DDIS during setup, forcing post-processing workarounds that introduce errors. - **Account number handling**: Inconsistent formatting (e.g., spaces/dashes) between systems causes template mismatches, requiring dual-format solutions to satisfy downstream reporting. - **Missing bill downloads**: Non-bill-pay accounts (e.g., three specific locations) had undownloaded September bills, indicating a pipeline failure for postpaid customers. ### Strategic Improvements Proposed solutions focused on systemic fixes rather than one-time corrections. - **Validation protocol enhancement**: Implement vendor verification for ambiguous units of measure during data capture, especially for historical imports. - **Template logic overhaul**: Integrate DDIS data (bill type, observation types) into DSS validations to eliminate manual classification rules. - **Account standardization**: Adopt uniform account-number cleansing (strip spaces, replace specials with dashes) across all systems to improve template matching reliability.

## Customer The customer, Victra, operates in the utility payment management sector. Their core function involves processing and paying a high volume of utility invoices on behalf of their own clients. Their background indicates they manage substantial financial reserves and require robust, scalable systems for payment automation, reconciliation, and detailed reporting. They are a sophisticated user, deeply engaged with the technical and operational nuances of the platform, and hold the service to high standards for accuracy, timeliness, and transparency. ## Success A significant success achieved for this customer is the architectural separation of emergency and non-emergency payment processing. This enhancement directly addresses a critical operational need by allowing the customer to clearly distinguish and reconcile different payment types. The work to split the associated AP files and fund pulls "to the penny" has been completed, providing a much clearer audit trail. Furthermore, ongoing development to visually separate these payments within the user interface is slated for completion soon, promising to further streamline their reconciliation workflow and provide at-a-glance clarity on payment statuses. ## Challenge The primary challenge centers on reconciliation timing and data visibility, particularly concerning emergency payments. While the funds for an emergency payment are pulled immediately, the corresponding AP file (which includes the processing fee) is generated later, often manually, causing a disconnect that hinders real-time reconciliation for the customer. Additional persistent challenges include managing uncashed checks over 30 days, where visibility into the reason for the delay (e.g., a utility only accepting checks) is limited. There are also specific issues with utilities like PG&E, where payments occasionally default to checks despite available electronic credentials, and a need for clearer SLA reporting and tracking for their payment processor's performance. ## Goals The customer's key goals for using the service are: - **Achieving seamless, real-time reconciliation**, especially for emergency payments, where fund pulls and AP file generation are synchronized. - **Eliminating manual workarounds**, such as operators manually adding fees to AP files, through greater automation and system integration. - **Gaining comprehensive visibility and reporting** on payment statuses, including a clear, actionable dashboard for tracking uncashed checks and the reasons behind their delays. - **Improving SLA transparency and accountability** through accessible metrics that show payment processor performance over time. - **Refining billing and reporting accuracy** by excluding mock bills from certain "missing bill" reports to reflect only actual, unpaid invoices. - **Ensuring high electronic payment success rates** by effectively managing and utilizing payment credentials for all utilities to avoid unnecessary check payments.

## Onboarding Challenges and Account Management Issues Several accounts remain unonboarded despite prior efforts, with 24 specifically flagged as problematic. Vendor-supplied lists failed to include these accounts, causing discrepancies. A new onboarding process for NGX accounts is required, but manual verification revealed mismatched account numbers between systems, complicating reconciliation. Customers are now reporting billing inaccuracies beyond known issues like double payments, including unexpected errors emerging over extended periods. ### Billing System Improvements - **Accrual report fixes**: Virtual accounts aren't linking properly, causing incorrect usage projections. Adding billing account IDs to reports will allow indirect linking by matching cleaned vendor/account combinations (hyphens/spaces removed). This enables customers to: - Identify unlinked accounts for closure - Accrue correctly by commodity type - **Account validation gap**: When web download teams select the wrong account during bill processing, errors cascade through systems. Implementing a pre-audit check will flag discrepancies between selected accounts and bill-captured account numbers for operations review. ### Payment Processing Complexities - **Duplicate payment fallout**: While Medline duplicates are resolving via credits/refunds, Constellation faces significant unapplied credits due to supplier reluctance to issue checks. Entergy requires manual intervention after payments were applied to wrong accounts. - **Emergency payment workflow**: Transaction fees now generate individual AP files for amount matching, but timing mismatches persist. Payment processors delay fee pulls by 1-2 days due to compliance constraints, preventing real-time synchronization despite customer requests. ### System Integration Gaps - **Legacy vs. modern system conflicts**: Setup builds originate in DDIs (legacy) before UBM mapping, causing data inconsistencies like account number formatting differences. Sales teams often bypass established workflows, creating unvalidated accounts. - **Location mapping bottlenecks**: Teams manually map locations despite existing bulk loaders, wasting resources. Automation adoption is critical as new clients (e.g., Ascension) onboard. - **Data synchronization failures**: Hundreds of accounts exist in UBM but not in core systems or master lists, indicating unauthorized invoice processing without proper setup. This caused Ascension to discover 1,000+ unlinked accounts during audits. ### Vendor-Specific Operational Hurdles - **Victra account discrepancies**: Payment volume dropped sharply due to unreconciled location naming differences between client-provided data and utility records. Disconnects persist despite repeated utility outreach. - **Constellation

## VPN Connectivity and Access Issues Participants encountered difficulties connecting to the VPN and accessing Microsoft accounts on personal devices. The error "your organization does not follow for this device" appeared during login attempts, blocking access to critical systems like DSS and FTG Connect. Workarounds were discussed, such as importing an XML configuration file for VPN access without logging into Microsoft accounts. However, this limited functionality for tools requiring Microsoft authentication. ## Ticket Status and Issue Resolution A double-counting ticket review confirmed no duplicate entries in three UBM bills, though line-item organization issues were noted. To resolve discrepancies, the team emphasized verifying CSV files from the portal: - **CSV validation process**: Downloading and comparing CSVs sent to UBM against source data to identify mismatches. - **Admin access utilization**: Leveraging portal permissions to directly retrieve CSVs for audit purposes. ## Development Updates and Blockers Progress on development tasks faced environment constraints: - **Script enhancements for Cosmos DB**: A new script was created to handle data without application changes, but encountered continuation token issues during record searches. Testing remained limited to a development database with partial records. - **FTG Connect development halt**: Local work stalled due to unresolved redirect URL dependencies in app registration, pending external support. ## Virtual Account Mapping Challenges Fundamental gaps in virtual account mapping logic were identified as a priority: - **Missing setup data integration**: DSS lacks access to initial account configuration details (e.g., supply/distribution/full-service flags) from DDS/UBM setups, causing validation issues. - **Data sourcing strategy**: Plans to pull account-specific setup information (e.g., service account formats, observation types) directly from DDS via existing SQL Server connections. This will enable consistent virtual account validation against customer expectations. ## System Enhancements and Task Prioritization Key operational improvements were outlined: - **Invoice reprocessing mechanism**: Implementing a daily cron job to handle failed invoices, moving beyond the current commented-out solution. - **Deferred tasks**: FTP folder tracking and DSS static uploads were prioritized over email tracking due to bandwidth constraints. - **Data verification urgency**: Immediate focus on reconciling UBM CSV files to close validation loops.

## Background The candidate's career began in consulting, working with Fortune 500 companies and early-stage startups. They transitioned to fintech as the founding Product Manager at Finmark, a Y Combinator-backed startup focused on financial planning and analysis tools for startups and SMBs. Following Finmark's acquisition by Build.com, they moved to Constellation (a major US non-fossil energy provider) as a Senior Product Manager/Director, currently owning their utility management platform. All professional experience is US-based. ## Work Experience - **Finmark Tenure:** Joined as the first employee after founders and spearheaded product strategy from inception through acquisition. Key contributions included: - Identifying core market segments and developing the "20% features for 80% impact" approach to capture early adopters. - Leading the entire product lifecycle as the sole product manager initially, later managing a growing team (reaching ~24 offshore and 7 US-based engineers). - Driving the critical strategic pivot from solely serving startups to targeting SMBs, which significantly accelerated growth and led to acquisition. - Facing significant operational challenges, notably high turnover within the offshore engineering team due to unsustainable workload intensity, highlighting the difficulty of retaining contractors versus invested employees. - **Constellation Role:** Currently owns and directs the development of the utility bill management platform, brought in to lead after the previous director departed. Focuses on managing and evolving this enterprise-scale platform. - **Working Style:** Demonstrated a hands-on, validation-driven approach at Finmark, working closely with engineering and design teams daily. Emphasizes defining problems, validating solutions, and executing roadmaps. Learned the importance of sustainable team structures and the need for strategic flexibility (e.g., the pivot to SMBs). ## Candidate Expectations - **Role & Opportunity:** Actively seeking the right opportunity, particularly within the burgeoning Saudi startup ecosystem. Expresses strong interest in early-stage, high-impact roles. - **Working Arrangement:** Open to starting with a remote work arrangement, with flexibility regarding future location adjustments ("not set in stone"). Values the ability to contribute effectively regardless of initial location. - **Industry & Technology Focus:** Deeply interested in fintech and startups, specifically those leveraging AI. Believes AI integration is critical for competitive advantage ("if you're not embracing AI... you're going to be left behind"). Sees the current Saudi market as a "level playing field" ripe with opportunity. - **Company Stage & Impact:** Drawn to early-stage ventures where they can play a significant role in building and shaping the product and company, similar to their founding role at Finmark. ## Questions/Concerns The candidate raised several strategic and operational questions: - **Market Strategy:** Inquired about the focus on the local Saudi market versus the broader international (Commonwealth) strategy, asking specifically, "Are you starting with the local market though?" and probing the transition from local connections to scalable customer acquisition ("How do you go from connection to a customer?"). - **Competitive Landscape:** Questioned the existence of established competitors ("I'm assuming since you're saying that there isn't already an established company that does that yet") and sought clarification on the competitive differentiation. - **Product Focus & Validation:** Asked for specifics on the initial customer use cases and value proposition ("they're mainly there for the agentic services... What exactly what part of their business is it just knowledge? Is it more than that?"). - **Primary Challenges:** Identified and questioned the perceived biggest next challenge post-funding ("what's the next big challenge for you?") and probed potential solutions for the identified go-to-market challenge ("And the solution for that you think is white or still question mark for you?"). - **Team Building:** Ended the interview seeking clarity on current team composition and hiring focus for co-founders or key early roles ("What's the team composition now? Looking for the co-founder? What you looking for?").

## Summary ### Issue Overview and Problem Statement The meeting focused on investigating a critical issue raised by the client (Hexal) regarding discrepancies in their natural gas usage data, where values in a custom report were significantly lower than those shown in the UBM portal and on actual bills. The core problem is that the report is displaying single-digit values for months where the usage should be in the thousands of therms, causing the client to believe the system is undercounting their consumption. ### Analysis of the Primary Discrepancy (TPA Location) The team conducted a detailed analysis of a specific example for the TPA location, focusing on the month of July. A key discovery was that the report's values are being misinterpreted due to unit conversion and bill calendarization. - **Unit Conversion Explained:** The underlying issue stems from how data flows through the system. The UBM portal displays usage in therms, but the client's custom report is pulling and presenting the data in **MMBtu**. The conversion from therms to MMBtu involves dividing by approximately 10, which explains why a reported value of ~54 therms in UBM appears as **~5.4 MMBtu** in their report. This is not a data error but a potential misunderstanding of the report's output unit. - **Bill Calendarization Clarified:** A related factor is the handling of bills that span multiple months. A single invoice's total consumption is split (calendarized) across the service months it covers. Therefore, the usage for a specific calendar month in the report is not a single bill's total but a pro-rated portion, which could appear unexpectedly low. ### Investigation of a Secondary Data Issue (Dyersburg Location) A second, more serious issue was identified for the Dyersburg location in April, where the report showed zero usage despite the bill containing a valid charge. - **Root Cause Identified:** The problem was traced to a **data classification error** within the bill's observations. The usage observation for this Constellation bill was incorrectly coded as a **generation consumption** type instead of a standard **total consumption** type. - **Impact of Misclassification:** Because the reporting logic sums usage based on specific observation codes, this misclassification caused the ~75.9 MMBtu (758.9 therms) of usage to be excluded from the total consumption calculations in the report. This constitutes a genuine undercount. ### Discussion on Historical Data and System Logic The conversation delved into the logic of how usage is classified and calculated within the system, highlighting a potential inconsistency in how historical versus live data is handled. - **Historical vs. Live Bills:** An investigation into past bills revealed that earlier ("historical") bills often used a simple `usage` observation, while more recent ("live") bills from the same supplier are being mapped with a `gen` (generation) observation code, even for full-service accounts where this classification might be incorrect. - **Need for Process Alignment:** This inconsistency suggests the problem with the Dyersburg bill is not a one-off anomaly but could be a recurring issue tied to the mapping logic from the data source (DSF). It necessitates defining the correct observation type for various billing scenarios to prevent future discrepancies. ### Resolution Path and Next Steps The team outlined a two-pronged approach to resolve the issues and prevent recurrence. - **Immediate Fix for the Dyersburg Bill:** The specific bill with the misclassified observation needs to be corrected by an admin user editing the bill to change the observation type from `gen` to the appropriate code for total consumption, which will allow it to be included in report totals. - **Long-Term Analysis and Rule Definition:** To address the root cause, a deeper analysis is required involving subject matter experts (like "Afton") and operations teams. The goal is to: - Clearly define the expected observation type for natural gas usage in different contexts (e.g., full-service vs. supply-only). - Understand and potentially correct the mapping logic from the data supplier to ensure future bills are classified correctly upon import. - This will help create a standardized rule to avoid similar misclassifications going forward.

## **Progress on Bill Data Extraction and Setup** This meeting focused on reviewing the status of data extraction from utility bills, updating the project timeline, and addressing dependencies for the upcoming client update. ### **Status of Non-EDI and EDI Bill Collection** The initial phase of downloading and organizing the raw bill data is nearly complete. A script has been run to separate bills into two key categories for processing. - **Non-EDI Bills:** A total of 7,412 non-EDI bills have been successfully pulled down and are sitting in a designated folder, ready for the next step. - **EDI Bills:** Work is underway to collect approximately 848 known EDI bills into a separate folder. This task is expected to be finished soon. These bills require a different, more time-consuming setup process. - **Image Link Resolution:** An issue concerning roughly 560 bills with missing image links has been resolved. It was confirmed that most of these were summary bills, and the actual PDFs have been received from the customer, so they do not need to be pulled via the script. ### **Updates to the Project Timeline and Gantt Chart** The project's Gantt chart was reviewed and updated to reflect current progress and newly identified tasks, ensuring an accurate picture for the upcoming client meeting. - **Completed Task:** The activity for downloading non-EDI bills was marked as 100% complete. - **New Critical Task Added:** A new line item was created for "Vendor Sender Setup / Bill Loading," which is the work currently being performed by Alberto. This task is a prerequisite for the data extraction phase. - **Timeline Adjustments:** The start date for the "UVM Account & Attribute Setup" task was adjusted, as it was discovered the work had not yet begun as previously scheduled. The team is confirming if a bulk upload tool can be used to accelerate this task, which would prevent a schedule delay. ### **Dependencies and Resource Challenges** A significant portion of the discussion centered on workflow dependencies and the need for additional resources to maintain the schedule. - **Vendor Setup Bottleneck:** The process of setting up vendors for the bills is a manual task currently handled by a single team member (Alberto). This work must be completed before data extraction can begin on those specific bills. - **Resource Strategy:** To avoid delays, the team is exploring assigning an additional resource to begin data extraction on bills where the vendor setup is already finished, allowing work to proceed in parallel. - **Bulk Upload Potential:** A major opportunity to save time was identified. The team is checking if a bulk upload tool can be used to load all location data into the system, which would be far faster than manual entry. Confirmation on the functionality of this tool is pending. ### **Legal and Contractual Items** Progress on necessary legal agreements was discussed, with some uncertainty around timelines. - **LOA (Letter of Agreement) Status:** The LOA with the legal team is still pending. The timeline for its completion is somewhat flexible, as it is not needed until a notice period begins in mid-January. However, there is a desire to finalize the red-line review process to avoid last-minute delays. - **FBO Setup:** Questions regarding the setup of FBO (likely Freight Bill of Lading) documents are being handled by another team. It was noted that the contact, Tim, is working on it and will reach out if any clarifications are needed from this group. ### **Preparation for Client Reporting and Next Steps** The team planned for an upcoming discussion about custom reports and solidified action items. - **Custom Reports Discussion:** A separate meeting is needed to dive into the mapping and specific requirements for custom reports. This meeting will involve key personnel from both the data and business sides to define scope and prevent uncontrolled expansion of the reporting requirements. - **Immediate Actions:** Assignments were made to follow up on the bulk location upload tool and to schedule the custom reports mapping meeting. The updated Gantt chart will be used to communicate progress and current timelines in the next client update.

## **Summary** The meeting focused on reviewing ongoing technical work, addressing several persistent issues, and planning for future infrastructure needs. Key discussions revolved around debugging a recurring permissions system failure, progress on development tasks, the necessity for a production-like testing database environment, and the potential re-enablement of a previously disabled system report. The team also emphasized the importance of formal work tracking. ### **Ongoing Technical Issues and Debugging** The team addressed several critical technical problems requiring immediate attention and investigation. - **Recurring Permissions Assignment Failure:** A significant permissions system bug, which was believed to be fixed the previous week, has resurfaced. This issue prevents developers from properly viewing and accessing key application components like the download of File Exchange. The problem involves complex database permission flags that are not updating correctly through the application, necessitating a deeper investigation to find a permanent solution. - **SQL Database Performance Incident:** A recent incident where the Bills table was being locked, degrading performance, was traced back to a specific developer's machine. The connection from that machine has been blocked as a resolution. ### **Development Work Updates and Tracking** Progress on assigned development tasks was reviewed, with a focus on accountability and visibility. - **URL Redirection for Web Application:** Work was completed to add URL sign-in and redirection functionality for the web application on port 5000 for two other developers. - **Invoice Splitting Feature:** Development on the invoice splitting feature has not yet started due to the developer being occupied with resolving the aforementioned permissions issue and other unrecalled tasks from the previous week. - **Importance of Jira for Tracking:** The team stressed the critical need to log all work and issues in Jira. This formal tracking system is essential for monitoring progress, providing visibility to stakeholders, and ensuring tasks are not lost or deprioritized when immediate issues arise. ### **Infrastructure and Database Strategy** A primary discussion centered on creating a robust testing environment that mirrors production to prevent future issues. - **Need for a Cosmos DB Replica:** There is a strong requirement for a replica of the production Cosmos DB to allow offshore developers to perform accurate testing with real production data before deploying changes to higher environments. This need arose from past issues where testing without production data failed to catch problems. - **Evaluation of Replica Options:** Three approaches were identified for evaluation: 1) simply reading directly from the production database (which carries a risk of performance impact), 2) creating a read-only replica, or 3) provisioning a full, separate testing replica. The team will research the cost-benefit analysis of these options, considering that the current production Cosmos DB is on autoscale, which can handle query spikes but at a variable cost. ### **System Reporting and Monitoring** The team discussed the status of internal reports and monitoring tools. - **Re-enabling the System Status Report:** The "builds" system status report, which was taken offline, is now considered safe to re-publish. The earlier performance issue was linked to a specific machine's activity, not the report itself. The plan is to re-enable the report and monitor closely for any adverse effects on database performance. - **Creation of a New SQL Database for Development:** A question was raised about the effort required to create a new database on the SQL Server for development purposes. While the exact effort is unknown, it was noted that production uses a different server (`SQL01`) than development, which is on a managed instance. The task was directed to a specific team member (`Andrew`) for execution. ### **Access Requests and Next Steps** The meeting concluded with a review of pending access requests and immediate next actions. - **Pending Access for NDS Products:** A developer (`Is`) has requested access on port 502, which is noted as a required action. - **Immediate Action Plan:** The immediate priorities are to fix the broken permissions system, research the Cosmos DB replica options, re-enable the system status report with monitoring, and address the pending port access request. The team planned to follow up on the database strategy in the next discussion.

## Summary The meeting centered on addressing persistent operational challenges within the bill payment system, planning the strategic direction for the upcoming year (2026), and resolving immediate data processing issues with a key vendor. ### **Immediate Data Processing Issue with Constellation** A specific, urgent problem was identified where invoices from the energy vendor Constellation were producing incorrect data, likely due to failures in the Optical Character Recognition (OCR) and Large Language Model (LLM) pipeline. - **OCR/LLM System Failure:** The discrepancy between the vendor's bill and the data captured in the UI is suspected to be a recurring issue with Constellation, attributed to their invoice's complex formatting (use of colors, boxes, and images) which confuses the automated data extraction system. - **Proposed Immediate Solution:** For the affected customer, a manual data override was agreed upon as the quickest fix. There was a consensus that the operational team should handle this correction internally rather than asking the client to do it. - **Long-term Strategic Fix:** A firm decision was made to move Constellation's data processing away from the current DSS (Document Schema Service) system entirely. Since Constellation provides data in XML format, the plan is to develop a direct, non-DSS pipeline to eliminate the error-prone OCR step for this vendor, which was described as an "embarrassing" necessity currently. ### **Broader Systemic and Operational Challenges** The discussion revealed deep-seated operational inefficiencies that are consuming developer bandwidth and hindering product development. - **Unsustainable Workload:** The current model requires developers to spend a significant majority of their time on firefighting and manual operational tasks (e.g., writing SQL queries for ad-hoc research) instead of building product improvements. This is directly impacting the ability to fulfill feature requests from sales and customers. - **Azure Migration Overhead:** A major ongoing project to migrate infrastructure from Google Cloud Platform (GCP) to Azure is consuming roughly 30% of development capacity. While necessary, this "lift and shift" project is a major distraction that doesn't deliver direct customer value or improve efficiency. - **Compliance Duplication:** The cloud migration is further complicated by compliance audits (like SOC 2), as controls must be re-evaluated and documented for both the old (GCP) and new (Azure) environments, effectively doing the work twice. A shift to cloud-agnostic audit partners was noted as a positive step to avoid this in the future. ### **Strategic Planning and Focus for 2026** Planning for the next year was a primary focus, with a clear emphasis on achieving stability before pursuing new features. - **Primary Goal - Stabilize Bill Pay:** The unanimous strategic focus for Q1 2026 is to achieve operational stability, specifically for bill pay customers. The core objective is to systematically address and eliminate the recurring issues that have plagued the past quarter, lowering the constant operational overhead. - **Stability vs. New Features:** Any product improvements pursued will be those that directly contribute to reducing the current operational burden. New feature development unrelated to this goal is expected to be pushed back. - **Proposed Structural Change - Dedicated Bill Pay Team:** A key proposal to quarantine issues involved creating a dedicated "bill pay" lane within the system. This would involve a separate UI view and a dedicated analyst focused solely on bill pay invoice issues, preventing them from cascading and consuming the entire team's bandwidth. - **Resource Allocation Philosophy:** The planning approach will involve assessing all required work (backlog, operational fixes, strategic projects) and then deciding how to resource it, without being constrained by current team structures. The idea of forming new, specialized teams to handle specific problem areas was floated as a possibility, rather than just distributing work across existing dev, CSM, and ops roles. - **Realistic Planning:** There was an acknowledgment that a significant portion (e.g., 40-60%) of any plan must account for unforeseen daily issues. The goal is to clearly define what work is non-negotiable and "not pushable," and to set correct expectations around deliverables based on this reality. ### **Analysis of Recurring Vendor Issues** The conversation highlighted a need for better analytics on system performance to identify patterns in failures. - **Vendor-Specific Error Rates:** A question was raised about whether the company tracks error rates at the vendor level to identify patterns, like the known issues with Constellation. This data is not currently analyzed but is recognized as valuable. - **Categorizing Known Issues:** The intention is to bucket common failure modes (e.g., formatting issues, missing date fields) to streamline troubleshooting and response when new problems are reported. The hope is that the number of these buckets does not grow significantly. ### **Next Steps for Strategic Alignment** Concrete actions were defined to formalize the strategic discussion and plan. - **Dedicated Planning Session:** A meeting has been scheduled for the following week to translate the high-level strategic focus into concrete milestones and a actionable plan for Q1 2026. - **Pre-Work and Alignment:** The participants will prepare by consolidating priority lists from different perspectives (product, daily operations, existing backlog) to ensure the plan is comprehensive and has full buy-in from all stakeholders before finalization.

## **Summary** The meeting focused on persistent operational challenges within the bill payment and data management systems, with discussions revolving around immediate firefighting for specific clients and the urgent need for underlying systemic improvements. Key themes included resolving duplicate payments, addressing chronic data mapping errors, redesigning internal reports for better visibility, and moving from reactive customer-specific fixes to proactive, root-cause solutions. ### **Current Bill Processing and Data Verification Backlog** A significant portion of the discussion centered on the manual effort required to process and verify a backlog of bills, particularly for clients like Victra and Ascension. While progress was being made, concerns were raised about the quality and risk of automated processing without manual checks. - **Manual Review Necessity**: For critical clients, there was a strong consensus that bills, especially those with flags like "process special" or threshold errors, must be manually reviewed before payment to avoid costly mistakes like duplicates or paying frozen accounts. - **Ascension's Threshold Errors**: A specific issue was highlighted with Ascension, where a batch of bills contained "threshold errors" that required manual resolution by their team, introducing potential delays if only one person was tasked with this. - **Resource Allocation**: The team was actively working through lists, with hundreds of bills remaining for Victra before shifting focus to other clients, underscoring the scale of the manual verification workload. ### **System Reporting and Data Structure Overhaul** The design and functionality of internal reports were scrutinized, with a plan to move from a static, cumbersome data dump to a dynamic, focused view that provides actionable insights. - **Dynamic Report Design**: The goal is to create a report that dynamically shows the status of the last month's bill and the current month's bill for each account, moving away from a sprawling multi-month data dump that is difficult to analyze. - **Key Data Points**: Essential columns for the new report include invoice date, due date, payment status, and commodity/utility type. It was noted that accounts can have multiple commodity types, which needs to be accommodated in the new structure. - **Foundation First Approach**: The priority is to establish a stable, working "base" report. Additional data points and tabs can be added later, but the initial build has been technically challenging. ### **Duplicate Bill Crisis and Financial Implications** A major pain point was the fallout from a batch of approximately 1700 bills that were processed without proper safeguards, leading to widespread duplicate payments. The Medline account was used as a primary example of the financial and operational mess created. - **Lack of Pre-Validation**: The duplicate payments occurred because critical validation checks-such as comparing the new bill's total amount and due date against the prior bill-were reportedly overridden or not in place during a bulk processing effort. - **Downstream Complications**: The duplicates have created a cascade of problems: credits sitting on customer accounts (e.g., a $15,000 credit applied to a future $47,000 bill), the need for cancellations and refunds, and general uncertainty about which bills actually require payment. - **Investigative Hurdle**: There is significant frustration and concern because there appears to be no accessible audit trail or backup documentation showing how the decision to process the 1700 bills was made or what checks were performed, making resolution extremely difficult. ### **Chronic System Mapping and Integrity Check Failures** The team delved into the technical root causes behind the ever-present "mapping" issues, where the system fails to correctly match incoming bills to the correct customer accounts in the database. - **Core Matching Logic Flaws**: The primary issue is that the system (UBM) requires vendor account numbers to match *exactly* with pre-mapped formats. Simple inconsistencies like leading zeros, dashes, or spaces cause failures, and there's no intelligent logic to standardize these variations. - **Recent "Fixes" and Their Limits**: Two recent system changes were noted: 1) enforcing checks for all six variables that make up a virtual account, and 2) adding new required fields. However, these have not reduced the volume of mapping errors. - **Suspicion of Manual Overrides**: A theory was proposed that operational staff might be manually correcting account numbers in ways that the automated system (DSS) does not recognize, causing the same accounts to fail mapping repeatedly instead of achieving a "one and done" solution. ### **The Imperative for Root-Cause Solutions Over Patchwork Fixes** A recurring and emphatic point was that focusing on individual customer issues is unsustainable. The team acknowledged that without addressing fundamental system flaws, problems will simply migrate from one client to the next. - **Systemic vs. Symptomatic Fixes**: The conversation stressed that troubleshooting issues like Medline's duplicates in isolation does not solve the underlying problem; it only temporarily resolves a symptom for one client. - **Integrity Check Scope Creep**: The "integrity check" stage, initially intended for onboarding mapping issues, has ballooned. It now catches a variety of problems, including data verification (DV) issues where totals don't match, indicating a blurring of error resolution pathways and a need for clearer process definitions. - **Need for Transparent Logic Updates**: There was a call for better communication about ongoing updates to system logic (like DSS matching rules) to ensure the entire team understands why certain issues may be appearing or persisting. ### **Specific Customer Account and Audit Issues** Several discrete customer problems were highlighted, demonstrating the variety of operational fires the team manages. - **Victra Account Disconnect Problem**: A disconnect order was processed correctly based on a client-provided list, but the utility proceeded with the physical disconnect despite a later client request to cancel. This illustrates challenges with utility communication and timing that are outside direct control. - **Victor's Missing Accounts**: An audit inquiry was mentioned regarding 24 accounts that appear to have never been onboarded from an original list. The hope was that these accounts were simply omitted from the source list, but it points to potential gaps in the initial data handoff or ingestion process. - **Medline as a Test Case**: Given its smaller size (~300 accounts), Medline was suggested as a manageable test case to develop and apply a method for systematically untangling duplicate payment scenarios, as manually reviewing all 1700 affected bills was deemed impractical.

## Summary ### Customer Account Priorities and Statuses The meeting centered on assessing the current workload and anticipating challenges from key customers, with a particular focus on three major accounts. - **Med XL is identified as the next potential high-volume challenge:** The account has approximately 300 items in its queue. The complexity is heightened because some bills arrive before their official due date, making it difficult to prioritize and process them clearly. - **Victra requires further understanding and stabilization:** While some progress has been made, the team acknowledged that they still need to "get their arms wrapped around" the Victra account to manage it effectively and reduce pressure. - **Jaco is currently quieter but expected to escalate:** With 162 items pending, Jaco has not been as intensive yet, but there is a strong expectation that their volume will increase soon. The account has a significant number of unprocessed items from November. ### Invoice Processing Trends and Analysis A detailed analysis of billing data revealed unexpected patterns in workflow, prompting a re-evaluation of capacity planning and bottleneck identification. - **Surprising discovery of low bill volume on Tuesdays and Wednesdays:** Contrary to the assumption that weekends cause backups, data from the past three months shows a consistent dip in invoices received on Tuesdays and Wednesdays, with Monday typically bearing the brunt of piled-up work from Friday through Sunday. - **The analysis aims to understand true processing capacity and bottlenecks:** The goal is to move beyond simple monthly capacity and understand if concentrated bill arrivals create unsustainable peaks, even with adequate overall staffing. - **Data integrity and utility billing practices are questioned:** The team debated whether the trend could be real, considering that utilities don't coordinate invoice dates. Questions were raised about whether the data (based on invoice dates, not receipt dates) or internal processes (like formatting delays) could be skewing the results. ### BDE System Integration and Impact Significant concerns were raised about the effectiveness and return on investment of the BDE (likely a third-party data extraction) system, as its promised benefits have not materialized. - **The system's impact on reducing manual work is not evident:** Despite onboarding over 20 utilities-including major ones like Constellation-into the BDE system, the team has not seen a corresponding reduction in the manual web download workload. Requests for more web download resources continue, contradicting the expected efficiency gains. - **Questions about account synchronization and process gaps:** A key uncertainty is whether all new customer accounts are being automatically sent to BDE for management. If this process is still manual or incomplete, it would explain why the system isn't alleviating the team's daily tasks as intended. - **A fundamental reassessment of BDE's value is prompted:** The discussion led to a pivotal question about whether continuing to invest in adding more utilities to BDE is worthwhile if it does not tangibly free up team resources or reduce operational pressure. ### Team Updates and Current Workloads The meeting included updates on team availability and the redistribution of responsibilities to cover absences and manage ongoing issues. - **Key team members are out this week:** Mary is out for the entire week, and Elizabeth was out sick on the day of the meeting, requiring others to monitor specific communication channels like the EBM chat for urgent questions. - **Contractor resources are narrowly focused:** Two contractors are dedicated exclusively to the three high-priority accounts (Victra, Med XL, and Jaco), but with over 600 items already in the queue, there is a recognition that this focused capacity may still be insufficient if all accounts surge simultaneously. - **Responsibility for monitoring specialized queries is delegated:** Tim was asked to keep an eye on the EBM chat for complex questions, particularly regarding AP files, that may arise in the absence of other team members. ### Ongoing Projects and Process Improvements The conversation covered several ongoing technical and procedural initiatives aimed at resolving persistent issues and improving system accuracy. - **Refining the bill processing and payment application logic:** A repeat of a process run by Ruben, which accidentally caused some duplicate payments, is being attempted with a revised query. The new approach aims to more accurately identify the true "prior bill" to prevent such errors when pushing large batches through for payment. - **Dealing with persistent audit inquiries on the Victra account:** The audit team continues to ask detailed follow-up questions about Victra, creating an additional reporting burden. The team expressed frustration, noting they had already provided data that was very close to accurate and now must investigate minor discrepancies. - **Shifting team focus from data cleanup to value-added work:** If the automated DB push process is successful, it should free up the team to work on more strategic tasks, such as improving utility-to-account mapping, rather than manual data correction. - **The immediate goal is to prevent service shut-offs:** A primary operational objective is to process enough bills to avoid any customer service disconnections, with specific concerns about pending items for the Jaco account from November.

## Summary ### Core Objective: Sourcing Sample Utility Bills The primary purpose of the meeting was to fulfill a request for sample utility bill PDFs from different vendors and commodity types. The goal is to provide these samples to an external party, Arcadia, who is awaiting the data. ### Methodology for Data Retrieval The process for gathering the required samples involves a two-step technical approach. First, a query must be executed in Cosmos to identify the specific bill IDs that match the desired criteria. Subsequently, these bill IDs will be used to locate and retrieve the corresponding PDF files from the search indices. ### Specific Requirements and Criteria The request has very specific parameters regarding the type and number of bills needed. - **Electricity Bills:** A total of five samples are required from specific vendors, including Duke and PGE. - **Gas Bills:** A total of five samples are required from vendors such as BGE and potentially Constellation. - **Water Bills:** Two samples are needed, but this part of the request was handled separately as the vendors for water had already been identified. ### Constraints and Clarifications Several challenges and limitations were identified during the discussion. It was confirmed that the current system interface does not allow for direct filtering of bills by their commodity type (electricity, gas, water), necessitating the use of a backend Cosmos query. Furthermore, matching bills to specific vendors is complicated because the vendor information stored in the system (e.g., vendor code or client name) may not exactly match the names as they appear on the bills themselves. One vendor listed in the initial request, "Direct," was unclear and was likely to be ignored.

## Summary The meeting primarily focused on reviewing the progress of work completed in November and planning for upcoming deliverables in December, with a particular emphasis on reporting, payment processing systems, and bug fixes. ### November Work Review A comprehensive review of the work completed in the month of November was conducted, confirming the closure of several key initiatives. - **Invoice Processing**: This item is now considered complete. The foundational monitoring capabilities have been successfully implemented, providing the necessary visibility into system capacity for future operations. - **Emergency Payments**: The development work for the initial phase, specifically for Victra, is technically complete. A minor bug was identified regarding the generation of unique numbers for multiple emergency payments processed on the same day, but this does not prevent the overall item from being marked as done pending final sign-off. - **Unplanned Work**: A significant portion of the team's time, estimated at 20-30%, was dedicated to unplanned activities. This included addressing various bug fixes and completing four new reports that were requested by different team members during the month. ### December Planning and Prioritization The discussion then shifted to the work planned for December, with a focus on establishing realistic timelines and prioritizing tasks. - **PayClearly Credentials & Data**: This is a high-priority item that needs to be completed in December. The work involves ensuring real-time data pullback and accurate payment status reflection within the PayClearly platform, which is a dependency for other features. - **Data Validation Errors**: For most validation errors, short-term fixes have already been implemented. However, the development of long-term, more robust solutions is not within the scope for December due to capacity constraints. - **Reporting Requests**: Several new reports were discussed for December development. The priority is on the "update processing time report" and the "system status report." The requester will finalize the requirements for these and other views to enable the development team to begin work promptly. ### Future Work and Dependencies Several items were identified as requiring further discussion or were moved to a later timeline due to dependencies or resource availability. - **Bank Initiation for Emergency Payments (Phase 2)**: The second phase of emergency payments is dependent on the PayClearly platform. A follow-up meeting is required to determine the best approach, which may involve either an API integration or a process change. This item is not anticipated to be completed in December. - **Upcoming Quarter Planning**: It was suggested that a future meeting should be dedicated to planning for the next quarter (January-March) to provide a clearer long-term roadmap and better estimate delivery timelines for outstanding projects. The creation of a team charter was also mentioned as an ongoing task.

## Project Kick-off and Initial Planning The meeting served as a formal kick-off for the Simon client project, introducing a dual-role project manager focused on both client support and process efficiency. Two key workflow meetings are scheduled for the following week to deconstruct the end-to-end process into a visual diagram, aiming to identify risks and integration points. The immediate objective is to demonstrate tangible progress by next week, with a primary focus on initiating file ingestion and portal setup. ## File Ingestion and EDI Account Strategy A central challenge involves processing approximately 8,800 accounts, which includes a mix of standard invoices and Electronic Data Interchange (EDI) accounts. A script is actively scraping image links for these accounts, with about 5,500 completed and 2,000 remaining, targeting completion by the next day. A critical strategic decision was made to proactively separate EDI accounts before loading, as loading them would be inefficient and their notes are often deficient. This approach will allow the team to focus on the larger volume of non-EDI accounts to show quicker progress, with a separate workstream established to handle the EDI accounts later. - **Separating EDI Accounts:** The plan is to parse out the estimated 2,157 EDI accounts upfront using the script, preventing the onboarding team from wasting time on them and ensuring a cleaner, more efficient process for the initial load. - **Constellation Accounts:** Approximately 300 accounts are with Constellation, and these will be handled through an internal resource, as the actual PDFs can be retrieved from internal systems rather than relying on the scraped image links. ## Portal Setup and Onboarding Process The team is preparing to begin the manual onboarding process for the non-EDI accounts, with the scraped PDFs currently stored and ready for loading. A team member, Alberto, has been assigned to start creating portals in the system (UVM). However, significant concerns were raised about the risks of portal creation. - **Risk of Breaking Credentials:** A major risk identified is the potential to accidentally "break" existing credentials for a utility, which could trigger a notification to the current supplier (NG) and inadvertently reveal the client's termination plans. - **Mitigation Strategy:** To mitigate this risk, the team decided to have Alberto focus exclusively on loading the readily available non-EDI bill images into the system as a first priority, holding off on any portal creation that isn't definitively safe. This ensures immediate, visible progress while a safer, more informed strategy for portal setup is developed. ## Resource Allocation and Priority Management A key discussion point was ensuring that resources are focused on the right tasks to maximize progress. It was confirmed that Alberto should immediately begin processing the 5,000+ already-scraped non-EDI invoices. To facilitate this, he will be granted access to the folder containing these files and will require training on the internal system (CEP) for handling Constellation bills. The team is actively working to provide him with the necessary access and documentation. ## Progress Tracking and Next Steps A tracking mechanism will be established using the master account sheet to monitor progress meticulously. This will include columns to mark accounts as loaded or identified as EDI, providing a clear view of what has been accomplished. The immediate action items are to send a kick-off email to the onboarding team and provide Alberto with access to the first batch of files to begin loading. Additionally, a separate list of 17 accounts with no available image links will be sent to the client for resolution.

## Summary The meeting primarily focused on addressing a critical database performance crisis affecting multiple applications, while also reviewing progress on key development initiatives and introducing new infrastructure monitoring capabilities. ### Critical Database Performance Issues A severe database performance degradation was identified, causing widespread application crashes and timeouts across multiple systems. The issue manifested as frequent "wait operation timeout" errors in applications like FDG Connect and DDIs, with logs showing over 55,000 calls to specific stored procedures within a single hour. Investigation revealed several concerning metrics: one particular update operation on the DSS bill table accumulated 7,047 seconds of runtime in just one hour, while the `FN_get_processing_due_date_three` stored procedure was executed approximately 100,000 times during the same period. The team ruled out recent infrastructure changes or script deployments as potential causes, noting that scaling configurations remained unchanged with three instances running normally. ### Technical Investigation and Root Cause Analysis Immediate diagnostics were launched using SQL Server Management Studio (SSMS) to identify problematic queries and resource bottlenecks. The investigation focused on several key areas: examining long-running queries that consumed significant database resources, analyzing queries with abnormally high execution counts, and checking for potential looping mechanisms in recently deployed code. Database metrics showed surprisingly low memory consumption at around 10%, eliminating memory pressure as the culprit. The team specifically examined a clustered index update operation that appeared to be causing table resorting, though no recent index changes were made to the build table. ### UBM Output System Enhancements Significant progress was reported on converting the UBM output system from batch multiple bills to single bill processing. This major architectural change requires substantial modifications to both the UBM output layer and underlying output code structures. The conversion is estimated to require several additional days of development work. Additionally, plans were discussed to transition from CSV to JSON format for bill information transmission to UBM, leveraging their newly added JSON acceptance capability. This format change would represent a more modern approach to data interchange. ### Infrastructure Monitoring and Visualization A new monitoring infrastructure using Grafana was introduced as a replacement for existing visualization tools. Grafana offers enhanced capabilities for capturing and analyzing application logs, providing more powerful visualization features compared to current solutions. The team discussed integrating error logging from file systems into Grafana to enable better monitoring of application issues and performance metrics. This represents a shift toward industry-standard monitoring practices that could provide deeper insights into system behavior and faster problem resolution. ### Cross-Team Collaboration and Support Coordination efforts were underway to assist with Asian migration tasks, with team members offering to help offload work from colleagues involved in the migration project. Graphics and visual assets were also submitted for review, though specific details about their purpose weren't elaborated during the discussion. The team emphasized maintaining communication channels for rapid response to the ongoing database crisis, with members available for immediate consultation if needed during the investigation.

## Summary ### Arcadia Integration Strategy The primary focus of the meeting was planning the integration of a new utility data provider, Arcadia, into the existing data processing system. The core strategy involves initially processing Arcadia's data via PDFs to minimize risk, as the logic for sending data to the ultimate destination (UBM) is not yet fully stabilized. A secondary, parallel path involves developing a script to convert Arcadia's provided JSON into the required DSS JSON format for future use. A significant architectural decision to be made is whether the system will "pull" data from Arcadia or if Arcadia will "push" it, with a preference for a setup similar to the existing "file watcher" model used for other vendors. ### Technical Implementation and Workflow A major technical hurdle identified is the need to enable the DSS (Data Services System) to accept and manage different workflows for different data sources. This is anticipated to be the most substantial initial development effort for the Arcadia integration. The process involves fetching data from Arcadia's API, which returns both a JSON and a path to a PDF, and then processing these files through a dedicated pipeline. The goal is to have a clear, tested process ready so that when Arcadia is contractually ready, the technical onboarding can be executed swiftly, tracking all steps from data fetch to final processing. ### Credential Management Overhaul A critical and parallel issue discussed is the current fragmented state of credential management across systems like Smartsheet and DSS. This causes operational confusion and potential data errors. The plan is to consolidate this into a single, authoritative system, likely a new database table, that syncs with all other systems. This new system would require that every set of credentials is explicitly linked to a specific customer and vendor, eliminating guesswork and ensuring data integrity. This overhaul is considered a prerequisite for a stable and scalable operation, irrespective of the Arcadia integration. ### Customer Identification and Data Routing A persistent problem affecting current operations is the failure to properly identify which customer an incoming bill belongs to, leading to "unmatched" bills. This occurs when files uploaded via FTP or email do not adhere to a strict naming convention that includes client code and account number. For the Arcadia integration, the solution is to anchor customer identification at the credential level; since the system uses specific credentials to fetch data for a specific customer, the resulting bills can be automatically associated with the correct client, bypassing the unreliable file-naming step. ### Vision for Future System and Onboarding A forward-looking vision was presented for a new, dynamic onboarding and reporting system. This system would feature a live Gantt chart to track customer onboarding and ongoing service SLAs, making bottlenecks and responsibilities transparent. Reporting would be dynamically tied to CRM data, ensuring metrics like progress toward goals are always based on the correct, scoped numbers. The entire process-from ingestion and data extraction to payment processing-would be tracked, allowing for quick identification of exactly where in the chain a failure occurred for any given customer. ### Operational and Sales Requests A separate operational request from the sales team to set up a demo customer account in the production environment was addressed. This was deemed a significant effort that would require involvement from multiple teams. Given the lack of a formal contract with the prospective client, the request was prioritized as non-urgent and is likely to be deferred, as it would distract from core development and integration work.

## Summary The meeting centered on prioritizing urgent operational tasks, with a significant portion dedicated to handling a sales-driven request for a UBM demo. Other critical discussions involved resolving systemic billing issues affecting a large volume of accounts and addressing a technical problem with late fee processing. ### UBM Demo Request for Evolution Broker The team evaluated a request from the sales team to generate demo bills for a potential broker client, Evolution, who is considering a contract. The request was deemed non-priority due to the lack of a signed contract and the high operational workload at the end of the month. - **Logistical Hurdles and Manual Effort**: Processing the demo bills is not a simple automated task; it requires significant manual setup from both Data Services and UBM Ops teams. This includes creating the customer account, mapping locations, and loading the bills, which constitutes a "decent amount of effort." - **Proposed Compromise and Timeline**: Instead of processing all 36 requested bills, the team agreed to a compromise of generating 10 sample bills. It was concluded that fulfilling the request for a demo the following day was not feasible. The plan is to push back on the urgency and handle the request the following week, with a specific process involving a team member named Alberto for Data Services setup. ### Ascension Account Bill Processing A major operational task was highlighted concerning the Ascension account, where a large number of bills are currently frozen and require immediate attention. - **Scale of the Issue**: There are nearly 600 bills that need to be unfrozen and re-parsed. This is a direct consequence of an issue with "current charges" that caused the bills to be frozen in the first place, indicating a significant data processing backlog. ### Late Fees Integrity Check Error A technical issue was identified where late fees are creating errors within the system's integrity checks, preventing bills from being processed correctly. - **Root Cause Analysis**: The problem stems from late fees being generated as separate, standalone blocks rather than as line items within existing bill records. This incorrect data structure causes the system's integrity checks to fail because it cannot map these isolated late fee blocks to a corresponding bill. ### Team Workload and Schedule Adjustment A decision was made to manage the team's capacity in light of the current workload and priorities. - **Meeting Cancellation for Focus Time**: The next scheduled meeting was canceled to give team members dedicated time to work through the existing queue of tasks, including the high-priority items discussed. This underscores the high-pressure environment and the need for focused execution. - **Victra Account Status**: A brief check-in confirmed that the Victra account was in a good state with no immediate issues, allowing the team to concentrate on the more pressing matters.

## Summary The meeting focused on prioritizing and assigning technical tasks to improve the efficiency and stability of the DSS system. A primary topic was the need to properly document and add notes for all automated processes that send bills to various data stages, such as account setup and audit data, to ensure clarity and prevent issues. This includes documenting existing logic for duplicate resolution and charge discrepancies. Progress was noted on several fronts, including the resolution of a unit of measurement error affecting numerous bills and the completion of the Simon onboarding process for file exchanges. The discussion also emphasized the importance of cleaning up the backlog of tickets in the "to do" and "in progress" columns to ensure the system runs smoothly. There was a strong emphasis on setting up a local development environment for FDG Connect to enable work on new tasks, and a plan to reassign some existing report work to free up capacity. ## Wins - Successfully pushed a fix for the unit of measurement error affecting 1,400 bills. - The Simon onboarding process for file exchanges has been completed and is confirmed to be working as expected. - An automated retry mechanism for DP failures is already in place and functional. ## Issues - A need to fully explore and document every stage where bill data is automatically sent to DDS, as some processes like duplicate resolution were not fully documented. - The "to do" column contains a backlog of "paper cut" tickets that need to be prioritized and addressed. - The double-counting lines issue for line items remains unresolved and requires investigation. - The FTP folder setup for the Simon onboarding process is still pending. - The local setup for FDG Connect has not yet been completed, which is blocking work on related tasks. ## Commitments - **Owner**: Explore and document every automated step where bill data is sent to DDS to ensure notes are populated correctly. - **Owner**: Work on adding notes to bills sent to the "account setup" stage, specifically for summary bills. - **Owner**: Investigate and resolve the double-counting lines issue. - **Owner**: Complete the local setup of FDG Connect to begin work on assigned tasks. - **Owner**: Take on some reassigned report work to help with workload distribution.

## Summary The meeting primarily focused on resolving several operational and technical questions regarding file storage systems, document processing, and data loading procedures for a specific client project. Key decisions were made on the chosen method for handling invoice data transfers and clarifications were provided on external paperwork. ### File Storage Solution for Invoice Data The central topic was determining the best method to transfer a large set of invoices, with a decision made to proceed with Google Drive. The discussion involved comparing different technological solutions and understanding the client's specific needs. - **Selection of Google Drive over FTP:** The consensus was to use Google Drive for transferring the invoice set, as it was deemed the most straightforward solution. This decision was influenced by the need to accommodate a broker in the process who had complained about file size limitations with other methods like zip files. - **Client Precedent and Setup:** It was noted that another entity, Ascension, had previously chosen Google Drive over FTP, though the specific reasons were not recalled. The action item is to create a shared Google Drive folder and confirm with the relevant team (Afton's team) that they can access it. - **Purpose and Scale:** The solution is specifically for a large set of invoices that are too bulky for a zip file, confirming the data transfer is not for live bills but for a batch processing need. ### FBO Paperwork and External Queries Clarification was provided on how to handle external documentation, specifically FBO paperwork, for a user named Simon. - **Document Completion Process:** It was confirmed that the FBO paperwork is sent via DocuSign, allowing the recipient to complete it digitally by entering information into the fields. The alternative of manually printing, filling out, and emailing the form was also confirmed as a viable, though less efficient, option. ### Data Loading and System Processing Updates were given on the status of data loading tasks and a broader strategy for processing different types of data files. - **Extension and Caskey Data Load:** There was an issue with file rejection during a data load, which is being addressed by breaking the file into smaller batches of approximately one thousand records at a time. The goal is to complete this loading process by the end of the day. - **Strategy for EDI and Non-EDI Files:** A significant decision was confirmed to process all remaining files-both EDI and non-EDI-together. A previous batch of 5,000 files has been processed, with an additional 23,000 files remaining. The plan is to load everything into a single system, with the downstream team (Afton's team) taking responsibility for differentiating between the two file types. This strategy is pending final confirmation in a meeting scheduled for the following day. ### Upcoming Deliverables and Client Reporting The conversation touched upon upcoming tasks and a discrepancy in a client report deadline. - **Onboarding Plan and Data Batches:** A meeting is scheduled for the next day to discuss the onboarding plan, and the necessary data batches have not yet been sent to the Data Science (DS) team. - **Tableau Report Timeline:** A concern was raised regarding a Tableau report for the Ascension project. The developer communicated a Wednesday completion date, whereas the client was expecting it by Friday, requiring further investigation to understand and align on the timeline.

## Payment Reconciliation and Issue Resolution The meeting focused on reviewing and resolving outstanding payment-related issues, primarily concerning data synchronization between systems. A significant portion of the discussion was dedicated to a list of approximately 400 payments that required review. The majority of these were found to be non-issues, consisting of $0 payments or negative amounts that did not require actual payment processing. The remaining payments were either sitting in the UBM system or were unprocessed; these were subsequently submitted for payment via a file sent to PayCleary, which was successfully loaded. The immediate action is to ensure PayCleary prioritizes processing these payments. Additional tasks were assigned for review, including: - **Updated Location Mapping:** An updated list for mapping locations is expected, and it requires review once received. - **Past Due Amounts:** Specific past due amounts from 2015 and 2016 need to be examined to resolve these longstanding items. - **Virtual Accounts:** Unmapped virtual accounts also require attention as part of the cleanup process. A broader, more automated method for identifying such payment issues is under development, but manual review of the identified items remains a critical step to ensure accuracy in the interim. ## Data Synchronization Challenges with PayCleary A central and critical topic was the data synchronization process between PayCleary and the internal UBM system. The current system is failing to reflect the true status of payments from PayCleary in a timely and accurate manner, which is causing reporting discrepancies and operational inefficiencies. The core of the problem is an implementation limitation where the system only checks for status updates on payments that were created within the last 10 days. This is insufficient because payment statuses, such as a check being cashed, can change long after this 10-day window-sometimes up to 40 or 50 days later. Consequently, payments that are marked as "Complete" in PayCleary may still appear as "Processing" in UBM, leading to confusion and inaccurate data for teams like Ascension that rely on UBM for their information. The primary goal is to modify this process to pull data in a more real-time fashion and ensure that the status of *all* payments in UBM accurately reflects their current status in PayCleary, regardless of the payment's age. A proposal to extend the update window to 30 days was mentioned, but the ideal solution is to move towards updating everything. ## Impact on Reporting and Future Capabilities The inaccuracies in the payment data have a direct and negative impact on downstream reporting and business intelligence efforts. The data pulled from PayCleary serves as the foundation for several Power BI reports. Because this source data is currently unreliable, these reports cannot be fully trusted or utilized effectively. Once the data synchronization issue is resolved, it will unlock significant reporting capabilities. With accurate and timely data, the team will be able to build valuable new reports, such as: - **An uncashed check report:** This would automatically identify checks that have been issued but not yet cashed, improving cash flow management. - **Payment data at the billing account level:** This would provide more granular insights into payment behaviors and account statuses. Currently, to circumvent the unreliable automated data pull, a manual process is in place where someone extracts data directly from PayCleary every morning and distributes it, highlighting the urgency of fixing the underlying system issue. ## Other Ongoing Operational Tasks Beyond the major data sync problem, the conversation touched upon other operational workstreams. The resolution of the payment clearance information from PayCleary was confirmed to be an internal responsibility, not an issue on PayCleary's end. The discussion also confirmed that work on the unmapped virtual accounts and the review of past due amounts would be addressed imminently. A follow-up with another team member is planned to understand the technical constraints behind the current data sync limitations and to chart a path forward for both short-term and long-term solutions.

## **Summary** The meeting primarily focused on reviewing a workflow status report for invoice processing and troubleshooting a project setup issue. A significant portion was dedicated to understanding the meaning and sequence of various workflow status columns in the reporting system, with the goal of creating a comprehensive visual map of the entire invoice lifecycle. Additionally, progress updates were given on two key development tasks. ### **Project Setup and Access Issues** A project labeled "FDG" has been set up successfully, but a UI display issue persists where headings and components are not visible, mirroring the problem observed on the live server. During the call, attempts to diagnose this issue revealed a potential permissions or access problem, as the application failed to load correctly even after confirming VPN connectivity and authentication. The resolution of this access issue was delegated for follow-up with another team member. ### **Archiving Functionality Development** The implementation for archiving files from prior to the current year is complete and currently undergoing validation. This process involves complex queries across both Cosmos and DDS databases. It was confirmed that the setup for a separate, monthly archiving process is not yet in place, but this was deemed a lower priority that could be addressed later. ### **Analysis of Operational Issues** Two recurring operational problems were highlighted for resolution. The first involves "unknown vendors," where a source of data leakage has been identified, providing confidence that there are no other underlying causes. The second issue concerns "do not use meters," which appears to be a documentation-related problem that has resurfaced despite previous fixes. The emphasis was on compiling a definitive list of these issues to address them comprehensively and prevent future recurrences. ### **Deep Dive into Workflow Status Report Columns** The core of the meeting involved a detailed walkthrough of a workflow status report to understand the meaning and sequence of each column, which represents a stage in the invoice processing pipeline. - **Client, Batch, and Original File Name:** These columns represent the hierarchical structure of incoming data, starting with the client, then the document batch uploaded by the user, and finally the individual original files within that batch. - **Bills Column:** This shows the total number of bills currently in the processing system, specifically excluding those in the "Ready to Send" status, providing a snapshot of active work. - **Account Setup:** This status indicates bills that cannot be matched to an existing account in the system, requiring a new account to be created before processing can continue. - **DSS IPS Column:** This is a consolidated column that encompasses multiple data processing steps, including Optical Character Recognition (OCR) and the LLM (Large Language Model) service, representing the core automated extraction and interpretation phase within the DSS system. - **Identification of Deprecated Workflows:** The discussion uncovered at least two workflow statuses-"Map Vendor" and a separate "OCR Service"-that are believed to be deprecated and no longer part of the active process, as their functions have been integrated into the DSS IPS phase. This highlighted a need to clean up the reporting view to remove historical or unused steps. - **Data Acquisition:** The purpose and current activity within this status column were unclear, requiring further clarification with the operational team to understand if it involves manual data downloading or another function. - **Audit Data:** This status represents bills that require human review before they can be sent, a step that exists outside the main DSS system, with a desire to eventually migrate this function into DSS for operator efficiency. - **Duplicate Resolution and Ready to Send:** These final columns are self-explanatory; "Duplicate Resolution" flags bills identified as duplicates, and "Ready to Send" represents bills queued for dispatch, which can sometimes get stuck due to failures in the output service. ### **Actionable Follow-ups** To solidify the understanding of the workflow, a key action item was assigned to compile a reference list mapping each status column to its corresponding workflow ID and a brief description. This will aid in building a complete visual representation of the invoice lifecycle and in cleaning up the report by confirming which workflow statuses are active versus deprecated.

## حجم السوق والفرص المحلية والعالمية تم مناقشة حجم السوق المستهدف بالتفصيل، مع التركيز على السعودية ودول الخليج. حيث يُقدر حجم السوق المحتمل بحوالي **65 مليون دولار**، مستنداً إلى عدد المؤسسات والشركات الناشئة التي تتزايد باستمرار. وأُشير إلى وجود أكثر من 4.3 مليون مؤسسة في المنطقة، مما يؤكد على وجود فرصة كبيرة. كما تم التأكيد على أن السوق **كبير جداً** ومتنامٍ، مع ظهور مؤسسات جديدة بشكل يومي. ومع ذلك، تم طرح تساؤل حول ما إذا كان التركيز يجب أن يقتصر على السوق المحلي أم التوسع عالمياً، حيث أن توطين الأفكار للمنطقة قد يحد من النمو مقارنة بتقديم منتج قابل للتسويق globally. ## استراتيجية المنتج والتموضع التنافسي تم تسليط الضوء على التحدي المتمثل في تحقيق **Product-Market Fit** محلياً مقابل عالمياً. نوقشت أهمية عدم الاقتصار على تقديم "نسخة محلية" من الخدمات، بل العمل على تطوير منتج يمكن أن ينافس على مستوى العالم. وتمت الإشارة إلى أن البدء بمشروع محلي قد يكون خطوة أولى ضرورية لاكتشاف هذا الملاءمة قبل التوسع. كما تمت مناقشة فجوة في السوق، حيث أن العديد من المؤسسات المحلية تواجه صعوبة في تنفيذ عمليات معينة يدوياً، مما يخلق فرصة لحلول أكثر كفاءة. ## دور الذكاء الاصطناعي في أتمتة العمليات والعلامة التجارية تم تناول موضوع **الذكاء الاصطناعي** كأداة حاسمة لتحقيق الاتساق والكفاءة في العمليات، خاصة في المجالات التي تعتمد على الإدخال البشري مثل العمليات التسويقية وإدارة العلامة التجارية. وتم ذكر مثال عملي حيث تم استخدام الذكاء الاصطناعي لتحليل وإدارة **هوية العلامة التجارية**، من خلال إنشاء قاعدة معارف تحدد شخصية البراند بناءً على مدخلات محددة (مثل 10 صور و 10 قرارات). هذه الأداة ساعدت في حل مشاكل **الاتساق** في المحتوى النصي (الكابشن) والإنتاج، وأظهرت كيف يمكن للذكاء الاصطناعي أن يحل محل العمليات اليدوية المعرضة للخطأ والتباين. ## نماذج التسعير والعملاء المستهدفين تم شرح نموذج تسعير يعتمد على نظام **الرصيد (Credits)**، حيث توجد باقات مختلفة تقدم 20 أو 45 أو 100 رصيد. وتم الكشف عن وجود عملاء حاليين، منهم من اشترك في باقة 100 رصيد شهرياً، وآخرون في باقة 20 رصيد سنوياً. تمت مقارنة هذا النموذج من حيث التكلفة والفعالية مع تكلفة توظيف مصمم جرافيك أو كاتب محتوى، حيث أن الحل المقدم يغطي مجموعة أوسع من الخدمات (التصميم، الفيديو، الموسيقى، الكتابة) بتكلفة قد تكون أقل. كما تمت مقارنة الأسعار مع ما تقدمه الوكالات المحلية، التي قد تتقاضى آلاف الريالات مقابل حزمة محدودة من الخدمات. ## التحديات والفرص في السوق المحلي تم تسليط الضوء على تحدٍ رئيسي يتمثل في افتقار بعض الشركات الدولية أو الإقليمية التي تدخل السوق السعودي للفهم الدقيق **للثقافة والخصوصية المحلية**. هذا يخلق فرصة للجهات المحلية التي تملك هذه المعرفة لتقديم خدمات أكثر دقة وملاءمة. وتم ذكر أمثلة على أخطاء ترجمية أو ثقافية ترتكبها شركات غير سعودية تؤثر على مصداقيتها. بالإضافة إلى ذلك، تمت مناقشة التحدي الذي يواجه **المستقلين (الفريلانسرز)** فيما يتعلق بعدم الاتساق في جودة العمل أو الالتزام، مقارنة بالشركات المنظمة. ## التوجه الاستراتيجي وآليات العمل المستقبلية تم التأكيد على أن القواعد التقليدية للتأسيس والتوظيف قد تغيرت، حيث ظهر مفهوم **Solo Founder** وأصبح ممكناً بفضل الأدوات الحديثة. ومع ذلك، تم التشديد على أن هناك عنصرين لا يمكن أتمتتهما بالكامل ويظلان حاسمين: - **التفاعل البشري مع العميل**: حيث أن العلاقة الشخصية والإنسانية مع العميل لا غنى عنها. - **مراقبة الجودة والرقابة**: ضرورة وجود شخص (مثل Account Manager) لمراجعة العمل وضمان مطابقته لمعايير الجودة قبل تسليمه للعميل. كما تمت الإشارة إلى إمكانية تطوير أدوات داخلية تعتمد على الذكاء الاصطناعي لخدمة العملاء بشكل أكثر تخصيصاً وكفاءة، بدلاً من بيع الوقت بشكل تقليدي.

## العميل المحتمل يمتلك الخلفية الأساسية في قطاع التكنولوجيا المالية (فنتك) حيث عمل فيه لفترة طويلة واكتسب خبرة واسعة. خلال هذه الفترة، تعلم دروساً قيمة عديدة لكنه قرر مؤخراً طي هذه الصفحة والانتقال إلى مرحلة جديدة تماماً تتمحور حول عالم الشركات الناشئة (ستارتوب). الدافع وراء هذا التحول هو إدراكه أن مشاريعه الجانبية كانت متسقة وأكثر استدامة مما اعتقده في السابق، مما دفعه إلى تأسيس مشروعه الحالي، "كراسة". يتمثل شغفه الأساسي في فهم الشركات بشكل شامل من خلال قراءة كل شيء عنها، وهو ما يحاول تحقيقه من خلال خدمته الجديدة. واجه تحديات سابقة في التعامل مع الوكالات والمستقلين، حيث شعر أنهم لا يفهمون احتياجاته الحقيقية، مما عزز قراره بإنشاء نموذج خدمة مختلف. ## الشركة تركز "كراسة" على تقديم خدمات براندينج شاملة للشركات، تشمل إنشاء Landing Pages، وبيتسليك، ومواقع إلكترونية، ومحتوى، وتصميم. الفلسفة الأساسية للشركة هي تقديم هذه الخدمات كحزمة متكاملة دون الحاجة إلى التعامل المباشر مع العملاء بشكل فيزيائي، حيث تهدف إلى إلغاء الوساطة التقليدية للوكالات والمستقلين. تتبنى الشركة توجهين تكنولوجيين حديثين: الأول هو "فلساك AI" الذي يركز على استخدام الذكاء الاصطناعي لتسريع عمليات المشاركة، والثاني هو "النتيجة كخدمة"، بهدف توفير حلول جاهزة للمؤسسين توفر عليهم قضاء ساعات طويلة في تطوير أفكارهم. تستهدف "كراسة" بشكل رئيسي العملاء المتواجدين رقمياً والذين يمكن الوصول إليهم عبر الإنترنت، مع التركيز الحالي على الشركات الناشئة. ## الأولويات - **إصلاح نموذج الخدمة:** معالجة الإشكالية الموجودة في التعامل مع الوكالات والمستقلين التقليديين من خلال تقديم خدمة موحدة وشاملة تغني عن الحاجة لهم. - **التركيز على الشركات الناشئة:** استهداف قطاع الشركات الناشئة كشريحة أساسية في الوقت الحالي، مع إمكانية التوسع لاحقاً ليشمل شركات أكبر. - **الاعتماد على التكنولوجيا:** تسخير الذكاء الاصطناعي وأتمتة العمليات لتقديم خدمات أسرع وأكثر كفاءة، مثل "فلساك AI" و "النتيجة كخدمة". - **تعزيز التواجد الرقمي:** الاهتمام ببناء تواجد قوي على منصات التواصل الاجتماعي والإنترنت بشكل عام، باعتباره قناة التواصل والتسويق الأساسية مع العملاء المستهدفين. - **التركيز على المشاكل القابلة للحل:** اختيار المشاكل التجارية البسيطة والواضحة والتي يمكن حلها بشكل فعّال، بدلاً من المشاكل المعقدة التي يصعب إثبات حلها.

## Summary The meeting focused on addressing critical issues causing approximately 700 invoices to be stuck in the DSS (Data Submission Service) queue, primarily due to two distinct root causes. A deep dive was conducted to understand the failure mechanisms, assess the current state, and outline the necessary corrective actions. ### Root Cause Analysis: Failed Invoice Reprocessing A significant issue identified was the lack of an automated system to handle invoices that fail initial processing. This has led to a large backlog that requires manual intervention to clear. - **Missing Automated Reprocessing:** It was confirmed that while a method for automated reprocessing exists in the code, it has been commented out and is not operational. The proposed solution is to review, refine, and reactivate this mechanism. - **Proposed Implementation Schedule:** The plan is to implement an automated nightly job to reprocess failed invoices, with a suggested execution time of 2:00 AM EST. This is considered a high-priority task that needs to be completed by the following week. ### Investigation into Stuck Invoices The discussion involved a live analysis of the DSS queue to quantify the problem and identify specific error patterns. The initial figure of 700 stuck items was refined to a more precise count of 624 invoices specifically failing in the DSS pre-audit stage. - **Quantifying the Problem:** A real-time query was executed against the system to pull all current error messages from the failed DSS audit workflow, providing a clear dataset for analysis. - **Discovery of Critical Failures:** The investigation revealed alarming instances of live bills from major clients (e.g., Victor, Constellation) failing the pre-audit process, indicating a systemic issue affecting real-time operations. ### Critical System Flaw: Client Identification Logic The most severe problem uncovered is a fundamental gap in the system's logic for identifying the client associated with invoices uploaded via the File Watcher (FTP), leading to a high rate of failures. - **Systemic Failure for File Watcher Uploads:** It was determined that the system possesses **zero logic** to determine the FDG client for bills ingested through the File Watcher. This means any invoice uploaded via this method is almost guaranteed to fail the DSS pre-audit with errors like "Unable to identify client." - **Immediate Operational Impact:** This flaw renders the File Watcher upload path functionally unusable for client billing until the underlying logic is implemented, as these invoices become permanently stuck in the queue. - **Potential Workaround:** A potential alternative for clients is to use the bulk upload functionality within FDG Connect, which may not be subject to the same identification issue. ### Action Plan and Communication Strategy A two-pronged approach was formulated to address the immediate crisis and prevent future occurrences, involving both technical fixes and stakeholder communication. - **Technical Verification:** An immediate action item is to confirm the existence and effectiveness of any client identification logic that parses information from the file names of uploaded invoices, as this was suggested as a potential but unverified existing feature. - **Stakeholder Communication:** Once the technical details are confirmed, a communication must be sent to the relevant team (e.g., Afton's team) to inform them that invoices are failing because the expected file naming scheme or client identification protocol is not being followed. This will help mitigate the inflow of new problematic invoices.

## Summary ### The Core Problem: Unknown Vendor Customers The central issue discussed was the occurrence of "unknown" vendor customers in the system. This problem arises when DSS fails to process a bill for any reason, preventing the system from correctly identifying and setting the vendor customer associated with that bill. A significant concern is that these "unknowns" do not trigger any alerts or appear in standard operator workflows, making them difficult to detect without manual intervention. ### Root Cause Analysis The primary source of these unknown records was traced back to the process of uploading bills through the FDG Connect platform, specifically when using the download helper feature. It was noted that during this upload method, information was not being retained properly before being sent to DSS, leading to the identification failures. While a recent fix was deployed to address duplicate bill issues, the fundamental challenge of identifying the vendor customer before DSS fully processes the bill remains a systemic design consideration. ### A Short-Term Monitoring Solution To address the immediate need for visibility, a new monitoring tool was introduced. This is a modified version of the system status report within Power BI, which now includes a dedicated view for tracking unknown vendor customers. This new report provides a queue-based overview, showing approximately 2,100 records currently stuck in the "account setup" phase, with smaller numbers in other queues like DSS IPS. The report allows team members to look up problematic batches using the provided document batch IDs, enabling manual investigation and resolution. ### Investigation and Cleanup Strategy Initial analysis of the unknown records suggests that a large portion are likely duplicates, many dating back to July and September, which have probably been repulled and reprocessed successfully since. The strategy for handling these involves a manual review process, with an expectation that most will be deleted from the system. The team plans to incorporate a daily check of the new report into their routine to proactively manage this issue moving forward. ### Long-Term Considerations and Next Steps The discussion concluded with an acknowledgment that while the new report provides a crucial short-term solution for monitoring, a more robust, long-term fix is needed to "stop the leakage" and prevent unknown unknowns from entering the system in the first place. The underlying design decision regarding how and when vendor customer information is populated from DSS was flagged as an area requiring further discussion and potential redesign.

## Summary ### Establishing the Baseline Invoice Count The meeting centered on finalizing and validating the correct baseline number of invoices for the utility billing platform. The confirmed figure is **2,755**, which includes some quarterly bills. This number is critical as it serves as the benchmark for all future billing cycles; any deviation from it signals a problem in the invoicing or payment process. The team is working to ensure this number is accurately reflected across all systems. - **Platform Updates and Duplicate Resolution:** A significant effort is underway to update the platform and resolve duplicate entries. A list of duplicates has been identified and is being actively worked on to either close the accounts or update the platform, with the goal of ensuring that accounts marked for "Ops Review" are not just flagged but are actually resolved and removed from the system. ### Urgent Resolution of Missing Invoices A critical issue involves approximately 400 invoices, with a subset of 55 for which invoices have never been received. Immediate action is required to resolve this today to prevent utilities from falling into arrears next week. - **Utilization of Mock Bills:** As a temporary measure, mock bills have been submitted for many of these accounts to facilitate payment and avoid service disruptions. However, there is a strong emphasis on solving the underlying root causes. - **Root Cause Analysis:** A deep dive is needed to understand why these invoices are missing. Potential causes include a lack of credentials, reliance on paper bills, or accounts that are new and will not appear on portals for several billing cycles. The team is committed to identifying the specific reasons for each missing invoice to prevent recurrence. ### Reconciliation of Past Payments and Vendor Reporting An analysis is being conducted to reconcile all payments made over the last three months (August, September, and October) to ensure 100% coverage for all accounts. The goal is to identify and resolve any variances, such as instances where an estimated bill was paid instead of the full amount. - **Vendor Request for Mock Payment Report:** A request from the client, Victor, for a report detailing all mock payments by vendor and amount was discussed. This report is anticipated to reveal a high percentage of mock bills versus actual bills, which could raise questions about the overall control and management of the billing process. - **Payment Method Corrections:** For the client Victra, 16 payments are being canceled and reissued via ACH, with an additional 130 payments scheduled for completion by the end of the day. ### Challenges with Vendor Onboarding and Credentials A major operational challenge identified is the high rate of check payments (approximately 40%) for the Victra account, which is believed to be a symptom of credential synchronization issues. When payment credentials are not available, the vendor defaults to issuing paper checks, leading to delays. - **Credential Sharing and Security Compliance:** The team is exploring solutions to ensure the vendor has the necessary credentials. Options include adding credential information directly to the payment files or improving the frequency of system synchronization. A significant consideration is the **security and compliance (SOC) implications** of sharing credentials, which may require implementing new controls even if it adds operational steps. - **Streamlining the Process:** The hypothesis is that by ensuring the vendor has complete and up-to-date credentials, the reliance on checks will drastically decrease. An audit is needed to verify what credential information the vendor currently has access to in their system. ### Resolution of Executive Sign-Off for Utility Access A roadblock remains in obtaining the necessary Letter of Authorization (LOA) for certain utilities, which requires an executive-level signatory. The vendor is attempting to find a workaround to avoid escalating the request to their CFO. - **Exploring Alternative Signatories:** The possibility of having another company officer, such as "Vinnie," sign the document is being explored to circumvent the need for CFO approval and expedite the process. Maintaining a clear paper trail of all LOA submission attempts is emphasized as a critical best practice.

## Summary ### The Core Challenge: Identifying EDI vs. Non-EDI Accounts The central issue discussed revolves around a significant data discrepancy that complicates the process of identifying EDI (Electronic Data Interchange) accounts within a large master list provided by the client, Simon. The client supplied a master list of 8,823 accounts, along with a separate list of 2,457 accounts they claim are EDI. However, attempts to reconcile these lists have revealed major inconsistencies, creating a bottleneck for the onboarding process. ### Data Discrepancy and Reconciliation Issues A critical problem is the mismatch between account numbers on the different lists provided by the client. When attempting to match the 2,457 EDI accounts against the master list, only around 849 accounts were found to match directly. This leaves a gap of approximately 1,300 accounts from the EDI list that cannot be reconciled with the master account numbers. The discrepancy is attributed to different formatting of account numbers between EDI and non-EDI accounts, such as the presence or absence of dashes and spaces, which prevents a straightforward automated matching process. ### Evaluating Potential Solutions The discussion explored several potential paths forward to resolve the data impasse and continue with the account onboarding. - **Requesting Clarified Data from the Client:** One proposed solution was to go back to the client, Drew, and request that they provide a pre-sorted list or the specific information needed to accurately slice the data. However, there is a strong concern that this request would be poorly received, as the client has already provided the data and expects the team to handle the identification process, especially given the unusually high $40,000 onboarding fee. - **Manual Identification and Loading Process:** Another option considered was a manual, large-scale effort to load all accounts and identify the EDI accounts through the setup process. This would involve loading all accounts into the data services platform, having operators process the ones with physical bill copies, and then separately handling the EDI accounts. The primary drawback is the immense amount of manual labor and time this approach would require. - **Proceed with Loading and Handle Exceptions:** A hybrid approach was suggested: begin loading all available accounts immediately to demonstrate progress. The team would process the 7,412 non-EDI accounts first, while parking the identified EDI accounts. For the EDI accounts, operators would attempt to pull physical bill copies and maintain a separate tracking list. This method accepts that the full scope of EDI accounts will only become clear as the work progresses. ### Recommended Path Forward and Resource Implications A consensus emerged to move forward with the third option: initiating the loading process for all accounts without further delay. The immediate plan is to start with the 7,412 non-EDI accounts to show weekly progress, which is critical for maintaining the client's confidence. The team will handle EDI accounts as exceptions, with operators keeping a dedicated list of account numbers that are identified as EDI during the process. Given the sheer volume of work and the high stakes of this client engagement-which includes potential future commodity supply contracts-a strong recommendation was made to secure additional dedicated personnel to manage this onboarding effectively.

## Data Validation and Invoice Discrepancies A critical issue was identified concerning significant data mismatches in processed files, specifically impacting invoice accuracy. The core problem stems from an incorrect column definition in a script run the previous day, which resulted in erroneous data outputs. A manual verification process was initiated to compare the files from the current day against the corrected versions from the previous day, revealing 124 specific invoices with discrepancies between key financial columns. The immediate plan is to isolate these problematic invoices by creating a new column that subtracts one value from the other; any result not equal to zero will flag an invoice for manual review. This is a high-priority issue as it has a direct and immediate impact on customer payments. ## Invoice Processing Workflow and Escalation The meeting highlighted significant bottlenecks in the invoice processing workflow, particularly concerning invoices from "Constellation." Frustration was expressed over the fact that three separate channels are supposed to be obtaining these invoices, yet failures still occur. A clear escalation path was defined: when invoices are not pulled in a timely manner, the issue should be escalated directly to specific senior individuals to demand immediate processing. The need to eliminate redundant efforts and hold the responsible channels accountable was emphasized to streamline this critical operational function. ## System Limitations and Reporting Halt Work on a key reporting piece has been completely halted due to unresolved, "unknown issues" within the "DSS" and "DDIS" systems. These system errors prevent the crucial action of marking customers with a specific status, which is a prerequisite for generating accurate reports. Consequently, all reporting dependent on this data is on hold until these systemic issues can be resolved, which is not anticipated until the following week. In the interim, the team will continue to rely on existing, static reports for their operational needs. ## Data Access and Centralization To improve collaboration and data accessibility, a decision was made to decentralize a key data source. Instead of its current location, the data will be moved to a shared platform like SharePoint. This move is intended to ensure that all team members have simultaneous and equal access to the information until a more permanent, integrated solution, such as a Power BI dashboard, can be developed and implemented. ## Cross-Functional Collaboration and Skill Gaps A need for better cross-functional collaboration was identified, specifically concerning the processing of invoices from the "gas" system. It was acknowledged that internal expertise for navigating this particular system is limited, creating a dependency on individuals from other departments. The plan is to leverage existing professional relationships with contacts who are proficient in the gas system to bridge this knowledge gap and ensure these invoices can be processed effectively.

## Summary ### Investigating Unknown Customer Data Issues An investigation was launched into a critical data issue where certain customers are being classified as "unknown" within the system, which is suspected to be a primary cause of missing payments and subsequent service disconnects. The core problem is that these customers appear to be stuck in the system, invisible to the teams responsible for actioning their accounts, leading to billing failures. A specific hypothesis was put forward suggesting the issue might stem from a process conflict, such as a vendor connection being excluded from the normal data flow but still being picked up by a secondary data audit process, creating a duplicate or orphaned record. The investigation was deemed urgent, with a plan to sync later in the morning to establish a concrete action plan and identify the root cause. ### Addressing Payment and Reporting for Prepay Q4 A separate but related topic involved the processing and reporting for Prepay Q4 acquisitions. It was confirmed that some data pertaining to this period had been received and required attention. The discussion indicates a need to ensure that the reporting for this specific quarter is accurate and actionable, particularly in understanding the movements and statuses of prepay and postpaid customers to provide clear insights for the team. ### Power BI Report Editing Constraints The feasibility of editing Power BI reports was briefly discussed, highlighting a significant technical limitation. It was confirmed that editing these reports requires a Windows environment and a corresponding license, as attempts to do so on a Mac were unsuccessful and required the use of a virtual machine. This constraint means that, for the time being, report editing is limited to team members with access to the necessary Windows-based infrastructure. ### Processing of ADI and Non-EDI Data The status of ADI and non-EDI data processing was reviewed. While the data services system (DSS) is technically capable of handling account setups for this data, there is a perception that the operational team may lack the full knowledge to execute this process effectively. Consequently, these items may still be funneling through a manual workflow, indicating a potential gap between system capability and operational execution that needs to be addressed. ### Request for Payclearly API Key A final administrative point involved a request for a Payclearly API key, which is needed for reporting or a new dashboard. The established procedure for obtaining this key is to initiate a request through a dedicated Slack channel involving specific stakeholders, who would then facilitate providing the necessary access credentials.

## Summary The meeting primarily focused on technical progress updates regarding system reports and data processing, followed by a strategic discussion on addressing systemic issues with unknown customer data. ### Duplicate Check Development Work is actively underway to develop a duplicate check mechanism for processed bills. The development involves creating a system to identify duplicate entries based on specific bill attributes: **invoice date, due date, and the amount due**. A task was noted as needing to be formally created to track this ongoing work. ### Unknown Vendor Bill Report Significant progress was made on a report designed to surface bills from unknown vendors. The core issue, which was preventing these bills from appearing, was identified and resolved. - **Root Cause and Fix:** A filtering condition within a procedure function was incorrectly excluding these bills. The logic was updated to ensure that "non-provider" or unknown vendor options now appear in the dropdown filters. - **Enhanced Data Visibility:** The procedure was further modified to include node records, which now allows unknown vendor client bills to be visible within the workflow steps view. - **Publishing and Permission Hurdle:** A separate issue prevents the report from being published successfully by the developer, which appears to be a **permissions-related problem** concerning the connection to the underlying data source. A workaround was identified where a user with admin access can publish the report without connection failures. ### Systematic Handling of Unknown Customers A deep-dive session was held to analyze the current state and usability of the unknown customer report, revealing critical operational bottlenecks. - **Current Data Snapshot:** The report shows a substantial number of bills (e.g., 2,700 in one category) that are stuck in the system, specifically within stages like "DSS and account setup." The major concern is that these bills **cannot progress through the workflow** because they are associated with unknown customers and thus are invisible to standard operational filters. - **Actionability and Usability Gaps:** The report in its current form lacks direct links to take action on these bills. It was questioned whether a link could be added for bills in the "DSS" stage, potentially requiring a query to Cosmos DB to retrieve the necessary details. - **Strategic Concerns:** The discussion culminated in a fundamental strategic question: how to make the report more actionable for the operations team and, more importantly, how to **systemically minimize the occurrence of unknown customers**. This points to a potential underlying issue with the current data intake or setup processes that needs to be addressed at a foundational level.

## Summary ### Error Code Validation and Configuration The discussion centered on configuring specific error code validations for certain clients. A request was made to re-enable specific errors, identified as part of the "2.5 series," for a select group of clients rather than universally. It was confirmed that this targeted re-enablement is technically feasible and would be actioned upon receiving a formal email request, leading to the creation of a development story. Furthermore, the logic and current status of error `2045` were clarified: this error is triggered when a bill's past due amount is negative (indicating a credit) and is currently enabled but set to auto-resolve, meaning it does not trigger active alerts. A related error, `2024`, was noted to handle scenarios with a positive past due amount. ### Transitioning from Product Tier to Service Level Filters A significant usability improvement was proposed to replace the existing "product tier" filter with a "service level" filter within the system's search functionality. The current product tier filter was deemed largely irrelevant for operational tasks, particularly when teams need to distinguish between critical billing types like "prepay" and "postpay." It was confirmed that the necessary service level data is already available from HubSpot and stored locally, making this transition viable. The change aims to streamline workflows, especially for teams manually analyzing customer data in Excel, and will be formally confirmed with stakeholders before implementation. ### Power BI Reporting and Data Definition Challenges A substantial portion of the meeting was dedicated to addressing inconsistencies in Power BI reports used for tracking the bill processing lifecycle. The core issue identified was a misalignment in how key data columns are defined and interpreted by different users, leading to conflicting reports and conclusions. The discussion aimed to establish a single source of truth for metrics like "date bill received," "date loaded," and "date processed." **Key Data Definitions Clarified:** - **Received to Loaded:** This metric represents the time between when a bill is marked as available for download (from DSS/DDS) and when it is successfully loaded into the UBM platform. - **Loaded to Processed:** This covers the time a bill spends within UBM, from being loaded until it is processed and marked as ready for payment. - **Processed to Pay File:** This is the final step, capturing the time from when a bill is customer-ready to when the AP process generates the payment file. **Identified Data Gaps and Next Steps:** A critical data gap was acknowledged: the Power BI dashboard only reflects data *after* a bill is pushed to UBM. Information about bills that are still in the download queue, being processed in DSS, or stuck in the legacy DDS system is completely absent from these reports. This creates a blind spot in the complete bill lifecycle. The agreed-upon next step is to obtain specific examples where reports from different users do not match, enabling a step-by-step analysis to pinpoint the root cause-whether it's differing definitions, incorrect filters, or a true data discrepancy. ### Bridging Data Silos for Comprehensive Reporting The conversation highlighted the overarching challenge of creating a unified view of the bill lifecycle by bridging data from two separate systems: UBM and DSS/DDS. The current reporting structure fails to provide a holistic picture, as it lacks data on the initial stages of bill processing that occur before data is sent to UBM. The historical focus has been on optimizing the "loaded to processed" phase within UBM due to its manual components. The new goal is to develop a comprehensive report that tracks a bill from the moment it becomes available for download, through its entire journey in DSS/DDS, and finally through the UBM payment pipeline, which would require at least five distinct data points for complete tracking.

## Customer The customer is a user of a utility bill management (UBM) and bill pay platform. Their role involves overseeing and managing the processing and payment of a large volume of utility bills for their organization. They have a background of using multiple UBM platforms from a client perspective, giving them a unique and practical understanding of what a user expects from such a service. They are deeply involved in the operational challenges and are focused on demonstrating the value of the service to their own internal stakeholders and clients. ## Success The most significant success with the product is its core function of processing a high volume and value of bills. For instance, the platform successfully processed $10 million for one client. This demonstrates the system's capacity to handle substantial financial operations and its essential role in the customer's accounts payable workflow. The ability to manage such scale is the foundational value proposition that justifies the service's use. ## Challenge The single biggest challenge is the **lack of reliable, accessible, and trustworthy data for reporting**. Manually compiling basic performance metrics-such as the number of bills processed, their total dollar value, and on-time payment rates-can take several hours per client. The data is inconsistent across different sources (e.g., the native UBM platform versus the payment vendor's system), leading to discrepancies and a lack of a single source of truth. This forces the team onto the defensive with clients, as they cannot easily counterbalance occasional late fees or disconnection notices with an overarching, positive narrative of performance and progress. ## Goals The customer's primary goals are centered on gaining data transparency and using it to improve client relations and internal operations. - To have immediate, push-button access to three fundamental metrics for any client: the number of invoices processed, the total dollar value of those invoices, and the on-time payment performance. - To "flip the narrative" from being defensive about individual errors to proactively promoting the overall good work being done. - To establish a clean, trusted dataset that serves as a single source of truth for both internal business management and client-facing communication. - To eventually develop automated, client-facing reports or an executive dashboard within the platform that displays these key performance indicators. - To track and demonstrate progress on specific operational projects, such as onboarding, by showing weekly progress metrics like the percentage of accounts loaded into the system.

## Summary ### PG&E Access and LOA Confusion A significant issue was identified regarding Pacific Gas and Electric (PG&E) account access. An unexpected Letter of Authorization (LOA) request was received, creating confusion because internal systems indicated that portal access with Multi-Factor Authentication (MFA) was already successfully established. The core problem appears to be that while the team can pay bills through the portal, the utility is refusing to conduct payment research over the phone without a formal LOA on file. This situation is considered a high-priority item as it is anticipated to be a major point of contention with the client, Victor. An immediate action was taken to pause any LOA submission pending an internal investigation to confirm the exact nature of the existing access and to avoid escalating the situation prematurely. ### Invoice Reconciliation Status The primary focus of the meeting was a large-scale reconciliation effort for client invoices. A detailed report was pulled, identifying approximately 420 accounts that were missing invoices with an October invoice date. Within this larger group, a critical subset of about 55 accounts was highlighted; these are accounts for which no invoices have been received for September, October, or November, making them the highest priority. The team is actively working to determine the status of these 55 accounts, investigating possibilities such as them being closed accounts, having quarterly billing cycles, or being affected by system linking errors. The immediate goal is to resolve the status of these 55 accounts by the end of the day to prevent any potential service disruptions. ### Duplicate Bill Management A major technical challenge impacting the reconciliation process is the prevalence of duplicate bills within the system. It was reported that for many accounts, the system has downloaded five to six duplicate copies of the same bill. This significantly complicates the invoice tracking and payment process. The development team is actively working on a fix for the "download helper" tool, which is expected to prevent these duplicates from being created in the future. In the meantime, the operations team is manually sifting through spreadsheets to identify and correct these output errors to ensure data accuracy. ### Payment Processing and System Linking The payment process itself is under close scrutiny. A specific procedure is in place for payments that have been in a "processing" status for over 20 days; these are being canceled and reissued, with a preference for electronic payments over physical checks. Furthermore, instances of duplicate payments were discovered, where a mock bill was paid and then the actual bill was also processed. These are being identified for cancellation and refund. A parallel effort is underway to address system linking issues, where bills are not properly associated with the correct client account numbers, leading to them appearing as missing. A dedicated resource is working through a list to manually link these accounts and resolve the discrepancies. ### Strategic Reporting and Client Communication There was a extensive discussion about establishing a single, reliable source of truth for key performance metrics to be communicated to the client, Victor. The goal is to confidently report on three key data points: the total number of accounts (aiming for ~2,815), the number of accounts with payments processed or in funding, and the number of accounts remaining. Currently, there is a lack of confidence in the numbers being pulled from various systems (UBM, Power BI, PayClearly), with slight discrepancies causing concern. The decision was made to postpone sharing new metrics until next Tuesday to allow time for the duplicate cleanup and system linking to be completed, ensuring that the reported numbers are accurate and defensible. The ultimate objective is to shift the narrative with the client to confirm that **100% of their bills are being managed and paid**, moving away from a perception of last-minute scrambling. ### Long-Term Vendor Onboarding Issues A separate, ongoing issue involves the onboarding of accounts with San Diego Gas & Electric (SDG&E). This process has been stalled for approximately three months, with the vendor providing the same response daily, attributing the delay to high volume on their end. Despite daily follow-ups and providing all necessary documentation including LOAs and account lists, no progress has been made. The team is considering escalating the issue by having multiple people from the team contact the utility to apply more pressure and determine if there are other individuals or departments within the utility that can be engaged to break the logjam.

## Summary The meeting focused on diagnosing and addressing critical bottlenecks in the invoice processing workflow, with a particular emphasis on download delays. The core issue identified is a significant lag-averaging 12 days in October-between when an invoice becomes available and when it is downloaded. This "receive to loaded" delay is now understood to be the primary constraint impacting Service Level Agreements (SLAs), far outweighing processing times within downstream systems like DSS and UBM. A major concern discussed is that the current operational capacity appears to be at its limit. The team is processing a high volume of invoices daily, but this is insufficient to handle monthly spikes and the existing workload. It was emphasized that onboarding any new customers under the current process would exacerbate the problem, leading to a further degradation of SLAs. The conversation explored whether the root cause is systemic, such as uneven daily invoice volumes that create temporary bottlenecks, or related to process and training, where personnel might not be retrieving all available invoices. Automation, specifically through the Arcadia solution, was highlighted as the necessary long-term strategic fix to outsource and streamline the download process. In the short term, the focus will be on gaining better visibility into the problem through data analysis and enhanced reporting to understand invoice date distributions and precisely define capacity limits. ## Wins - **Identification of the Primary Bottleneck:** The main issue causing SLA failures has been successfully pinpointed to the "receive to loaded" timeline in the download process. - **Effective Downstream Processing:** Performance in systems like DSS and UBM is considered relatively strong and is not the primary source of the current delays. - **Progress on Reporting:** Development of a Power BI report is underway to provide better visibility into processing times and will serve as a foundational tool for ongoing monitoring and troubleshooting. ## Issues - **Critical Download Delays:** The average time to download an invoice after it becomes available is unacceptably high, peaking at 12 days in October, which is the main driver of missed SLAs. - **Capacity Limit Reached:** The current team is operating at its maximum capacity for manual downloads. The existing volume, coupled with uneven daily distributions, means the team cannot keep up with demand, especially during peak periods. - **Threat from New Business:** Onboarding new customers is not feasible without first resolving the capacity constraint, as it would immediately worsen the situation. - **Process and Data Gaps:** There is a lack of clarity on whether the download issue is purely a capacity problem or also involves process gaps, such as personnel not downloading all available invoices. Data on invoice date distributions to identify daily spikes is also currently unavailable. - **System Duplication:** Issues with FDG Connect causing some invoices to be processed multiple times are consuming valuable bandwidth, though this is a secondary concern to the core download delay. ## Commitments - **Data Analysis on Invoice Distribution:** An analysis will be conducted to graph invoice dates for specific customers (e.g., Victra) to identify if daily volume spikes are a contributing factor to the delays. - **Enhanced Reporting:** Development will continue on the consolidated Power BI report, with a commitment to add features like filtering by customer type (e.g., "Bill Pay") to provide more targeted insights. - **Investigation into System Issues:** A deeper dive will be undertaken with the relevant teams to investigate and resolve the duplication issues occurring in FDG Connect. - **Contract and Role Transition:** The process for converting the contract into a full-time position has been initiated with HR, and both parties will track progression toward this goal.

## Summary ### Invoice Lifecycle Report Analysis The primary focus was on evaluating the newly requested invoice lifecycle report and its relationship to the existing "lab" report. The discussion centered on whether the new report provided unique value or if its functionality could be merged into the established system. It was determined that the lifecycle report was strikingly similar to the existing lab report, leading to a strategic decision to avoid creating redundant, stopgap solutions. The consensus was to enhance the lab report with any necessary additional columns from the lifecycle report, thereby creating a single, authoritative source of data for tracking invoice statuses, particularly for high-priority clients like Victra. ### Escalating Duplicate Invoice Issue A critical and worsening problem with duplicate invoice downloads was identified. The team has observed a dramatic increase, from historically around 50 duplicates per month to now experiencing *hundreds of duplicates per day*. This surge is placing a significant manual burden on the team, requiring them to review and delete thousands of entries individually. While the system's duplicate check is functionally marking items correctly, the sheer volume indicates a fundamental breakdown in the process that prevents these duplicates from being downloaded in the first place. The example of the "Blue Ridge Mountain EMC" account was highlighted, where the same invoice was downloaded over ten times across multiple days, demonstrating the severity of the issue. ### Root Cause of Duplicate Downloads The investigation into the duplicate problem pinpointed a likely issue with the "snooze" function within the FDG Connect / Web Download Helper system. The intended behavior is for a processed invoice to disappear from the download queue until its next billing cycle. However, evidence suggests that tasks are repopulating in the download helper *after* they have already been processed and completed. For instance, an invoice processed on September 14th was subsequently downloaded again on September 26th, 30th, and multiple times in October, which should not be possible. This indicates a potential bug where the system is merely snoozing tasks for two days without respecting the invoice's processed status or its full billing cycle duration. ### Account Validation and Processing Errors A separate but related issue involves invoices being processed under incorrect account numbers. The system's current validation is insufficient to catch when a user manually uploads a bill to the wrong account in the Web Download Helper. In one case, an invoice for account 6300 was uploaded and processed under account 6301. The lack of a mandatory, human review step for every bill means these errors can flow through the system unchecked. This problem is compounded by past issues with the Web Download Helper interface, such as account lists reordering, which increases the likelihood of user error during manual uploads. ### Data Reporting and System Integration The conversation also covered challenges with data consistency across different reporting systems. There was confusion regarding a specific Power BI report, as the origin and data definitions for columns like "Invoiced/Received" and "Received/Loaded" were unclear. The team expressed skepticism about how an external system could accurately track when a physical bill was received via mail versus downloaded. This highlights a need for clearer data lineage and definitions between the Data Services System (DSS), the legacy system, and any external reporting tools to ensure all stakeholders are working from the same understood metrics.

## Summary The meeting focused on the critical and urgent need to stabilize the billing and payment processes for a major client, Victor, following persistent issues that have led to service disconnection notices and significant financial damages. The situation is described as "shameful" and requires immediate, all-hands-on-deck resolution by the end of the week, especially with the crucial holiday retail season approaching. The core of the problem is a multi-faceted breakdown in the invoice-to-payment lifecycle, involving delayed downloads, systemic duplicates, and processing bottlenecks. The team is tasked with conducting a deep-dive analysis to identify every point of failure and implement solutions to ensure all ~2,800+ monthly accounts are paid on time to prevent catastrophic service interruptions and further financial penalties. ### The Urgent Business Crisis The client situation has escalated to a critical level, demanding immediate and comprehensive action from the entire team. The stability of the Victor account is paramount, with significant financial and contractual repercussions already in motion. - **Severe Business Impact**: The client is preparing to charge $65,000 in damages for issues to date, with the potential for more charges or even contract cancellation. This problem is noted to have a potential ripple effect across the entire organization. - **Imminent Operational Risk**: The upcoming Black Friday and Christmas holiday season represents the client's peak revenue period. Any service disconnections during this time would be catastrophic, as their store employees work on commission and lose income when systems are down. - **Clear Deadline**: A firm deadline has been set to solve these issues by the end of the week. The team must achieve a state where they are comfortable that all payments for November will be made on time to avoid further disconnection notices. ### Establishing the Account Baseline A primary step was to confirm the exact number of active accounts to establish a clear target for monthly payments and identify discrepancies in the system. - **Active Account Count**: After reconciling data, the team established there are **2,814 active accounts** that require monthly payment. This figure was derived from an initial 3,138 accounts, minus 184 closed accounts and 141 accounts that are open but flagged for closure or linking to another account. - **Credentials and Invoice Sources**: Of the 2,814 accounts, 2,420 have credentials set up for portal-based invoice downloads. The remaining ~300+ accounts receive paper or emailed invoices, which are manually processed. A specific challenge was noted with 51 accounts from utilities SDG&E and SoCalGas that still lack portal access. ### Diagnosing the Invoice Processing Bottlenecks The central focus of the discussion was a detailed forensic analysis of the invoice lifecycle, using a custom report, to pinpoint where delays and failures are occurring. - **The Critical Delay**: The most significant bottleneck identified is the time between an invoice becoming available and it being downloaded into the system. This initial step is consuming a large portion of the total processing time. - **The Mock Bill Dilemma**: A specific issue was uncovered where "mock bills" created on September 30th are disrupting the automated download schedule. In one examined case, an invoice with an October 9th date was not downloaded until November 2nd, and the subsequent November invoice had not been downloaded by the meeting date (November 19th), risking a late payment. - **Systemic Duplicate Problem**: The data is plagued by a high volume of duplicate bill downloads, estimated at around 3,000 entries. This creates massive inefficiency, as team members waste time processing the same invoice multiple times, and it obscures the true state of what has been processed. ### Technical and Systemic Hurdles Beyond the initial download phase, several technical issues within the Data Services (DS) and UBM systems are creating further delays and operational headaches. - **Data Services (DS) Processing**: While improving, the DS system still takes an average of 3 days to process invoices after they are loaded. A major contributor to this is the "broken batch" issue, where a single invalid bill in a batch causes the entire batch (sometimes 100+ good bills) to be deleted and reprocessed. - **UBM Mapping and Validation**: Invoices are getting stuck in IC&DV (Invoice Coding and Data Validation) and DVO2 stages, often due to missing location mappings or other attributes. While some automatic mapping is in place, a number of accounts still require manual intervention and information from the client. - **Payment Method Inefficiency**: The continued use of paper checks was highlighted as a risk factor due to longer mailing times. A push was made to urgently increase the number of payments made via ACH and credit card to reduce the payment execution timeline. ### Path Forward and Action Plan The meeting concluded with a clear directive to make the diagnostic report actionable and to prioritize fixes that will have the most immediate impact on stabilizing the process. - **Making Data Actionable**: The team will work overnight to cleanse the report of duplicates and use it to create a definitive list of accounts requiring immediate action for November invoices. This includes downloading missing bills and ensuring all 2,814 target accounts are accounted for. - **Targeted Technical Fixes**: Key technical improvements were prioritized: fixing the duplicate download logic, changing the system to snooze bills for only one day (instead of two) to speed up reprocessing, and modifying the "broken batch" logic to fail individual bills instead of entire batches. - **Daily Tracking and Accountability**: The team must synchronize around the goal of processing and paying for all 2,814 accounts each month. A clear, daily countdown or tracking mechanism is needed to provide visibility and ensure the target is met.

## Data Integration Between UBM and Data Services The meeting focused heavily on establishing data connectivity between UBM and Data Services to enable cross-platform reporting capabilities. The immediate priority involves creating a mechanism to pull data from UBM into Data Services' Power BI environment, with future plans for bidirectional data flow. - **Initial Data Flow Strategy**: The team decided to start by pulling UBM data into the existing Data Services Power BI infrastructure rather than creating new accounts for UBM users. This approach allows leveraging current access permissions and avoids the complexity of account management across organizations. - **Technical Implementation Details**: Discussion centered around identifying the UBM database location and establishing secure connections, potentially requiring IP whitelisting or other authentication methods. The UBM data resides in a read replica rather than the production database, which may simplify access. - **Report Structure Planning**: A new dedicated workspace will be created within Power BI specifically for UBM-related reports, maintaining logical separation from existing Data Services reports while enabling future combined reporting capabilities. ## Infrastructure Optimization and Scaling The team reviewed current system performance and identified opportunities to optimize resource allocation based on recent stability improvements. - **VM Scaling Reduction**: With recent performance issues resolved, the team approved scaling down virtual machine resources to more appropriate levels. This optimization will proceed gradually with monitoring to ensure system stability. - **Client Version Management**: An outdated client version was identified, though it's not currently causing operational issues. The team noted the need for a streamlined update process for non-technical users. ## Workflow and Process Improvements Several operational workflows required attention, particularly around duplicate resolution and batch processing failures. - **Duplicate Resolution Enhancement**: The duplicate resolution application will be updated to include checksum validation when identifying duplicate bills. This addresses an issue where bills sent to duplicate resolution weren't being properly matched due to missing metadata fields. - **Batch Processing Optimization**: To minimize the impact of processing failures, the team discussed breaking batches into individual bill processing rather than handling complete batches. This change would isolate failures to single bills rather than affecting entire batches. - **Error Logging Standardization**: Multiple validation checks have created fragmented error logging, requiring consolidation into a unified logging approach for better monitoring and troubleshooting. ## Future Planning and Automation The discussion included longer-term considerations for automating data exchanges and preparing for expanded service offerings. - **Bidirectional Data Exchange**: Future requirements include automated data flows from Data Services to UBM, potentially using the same infrastructure being established for the initial UBM-to-Data-Services connection. - **Expanded Service Offering Preparation**: The logging and monitoring improvements will support plans to offer Data Services to additional Constellation Navigator customers in the future, requiring robust, scalable infrastructure. - **Ticket Management Process**: The team emphasized using JIRA for tracking all work items, with integration to Teams messages to automatically create tickets with proper context and references.

## Summary The meeting centered on resolving payment processing and funding discrepancies with a business partner, specifically analyzing why certain invoices incurred late fees and identifying systemic issues in the funding reconciliation process. ### Funding Timeline and Discrepancies A detailed examination of a specific payment batch revealed confusion regarding funding dates and the root cause of delays. The discussion clarified that while funds were received within a reasonable timeframe, a misalignment in how dates are recorded by the partner's team is creating perceived delays. - **Investigation of a specific payment:** A payment of $1.66 million was received on November 19th, which was deemed timely. The partner's system, however, showed a "doc date" of November 15th, which was impossible as the payment file was not sent until November 16th. This indicates an internal logging issue on the partner's side that misrepresents the timeline. - **Identifying the core issue:** The primary problem is not necessarily the speed of funding but the accuracy of the amounts funded and the misalignment of internal dates, which complicates the analysis of what caused specific late payments. ### Payment File Reconciliation Process The core of the operational challenge is reconciling the amounts sent in daily payment files with the amounts actually funded by the partner. - **Ideal vs. Actual Process:** The ideal process involves sending a daily "Medline payment file" with a total amount due, which the partner should fund exactly. In practice, the partner often combines multiple payment files into a single transaction and sometimes funds an amount that does not match the sum of the files. - **Manual analysis is required:** A significant amount of manual effort is needed to match the funded amounts received against the individual payment files sent. This process is complicated by instances of underfunding and the aggregation of files, making it difficult to pinpoint which specific invoices were delayed due to a lack of funds. ### Impact of Underfunding and Aggregation The meeting detailed how the partner's practice of aggregating payments and occasional underfunding directly impacts the payment of invoices. - **Consequences of underfunding:** When a payment file is underfunded, it creates a funding gap. Pay Clearly, the payment processor, must then manually decide which invoices within that batch can be paid with the available funds, leading to delays for the remaining invoices. These delays can have a cascading effect, as subsequent files may also be impacted. - **Challenges in attribution:** It is difficult to directly link a specific late fee to a specific instance of underfunding that may have occurred weeks prior, as the funding is often "caught up" in a later, lump-sum payment. ### Defining the Problem and Strategic Approach The conversation shifted to formally defining the problems and deciding on a strategic response to the partner. - **Clarifying the problem statement:** The fundamental issue is confirming that the partner funds each payment file with the exact amount requested. The secondary issue is the partner's practice of combining multiple files, which, while not a problem in itself if funded correctly, complicates reconciliation. - **Strategic communication:** A plan was discussed to reply to the partner by highlighting two key points: the operational difficulty caused by combining multiple payment files into single transactions, and the confirmed instances where files were underfunded, leading to payment delays. ### Resolution and Path Forward A decision was made on how to proceed, balancing the need for a resolution with the reality of limited resources. - **Forgoing a deep-dive analysis:** It was agreed that conducting a exhaustive, line-by-line analysis of all historical payment files to dispute late fees is not a prudent use of time given current resource constraints. The effort required would be disproportionate to the amount of money in dispute. - **Proposed solution:** The path forward involves sending a communication to the partner that firmly reiterates the need for them to fund payment files on a one-to-one basis. The goal is to use clear examples of funding inaccuracies to convince them to change their process, thereby preventing future issues, rather than spending excessive time litigating past late fees.

## Summary ### Virtual Location Mapping Progress Significant progress was made on mapping previously unmapped virtual locations for billing data. Out of an initial batch of approximately 700 locations, around 600 were successfully mapped and approved. The remaining ~100 present a greater challenge as they are tougher to verify, primarily because they are not matching against the expected "last string" data, which is a crucial identifier for Banyan customers. The team is actively working on improving the matching logic to increase the automation rate and reduce the manual review burden. - **Processing a new, updated dataset:** A new data export was initiated to capture the most current state of live bills, which now number around 1,800, with 2,500 bills in total across the system. The updated mapping logic will be run against this new dataset for a fresh round of review and approval. - **Focus on streamlining approvals:** A key objective is to refine the process so that approvals for mapped locations are as effortless as possible for the team, minimizing the time and effort required for verification. - **Future development for comprehensive mapping:** A more advanced mapping logic that considers all six data points constituting a virtual account is planned. However, this enhancement is estimated to be at least a week away due to its complexity, meaning the current process will continue on a daily basis for the immediate future. ### Billing Data Verification and Processing The team is managing a substantial volume of bills in the data verification stage, with a focus on clearing errors and processing bills for payment. The daily throughput for the data verification team is typically between 100 and 150 bills per person. A specific query-based script was previously used to process a large batch of bills, successfully clearing out 1,700 bills from a particular environment. The team acknowledged that while this method is effective, it carries a inherent risk of missing certain edge cases where "mock" bills and "actual" bills might be out of sequence, potentially leading to double payments if not carefully managed. - **Addressing specific customer billing issues:** For the customer "Ascension," specific scripts are being run to handle bills dated before and after November 1st. This involves special processing to flip project codes, remove capacity balances for current charges, and re-parse the bills to resolve errors important to the customer. - **Clarification on bill types:** The discussion clarified the distinction between "history" bills and "special" bills. History bills are for periods prior to a customer's official go-live date and are loaded as a separate charge. Special bills are typically used for Accounts Payable (AP) or Bill Pay customers, often to delay or control payment. - **External reporting and expectations:** There is an established routine for reporting numbers to an external stakeholder, with updates typically sent around 8:00-8:30 AM and again in the evening. This reporting explicitly excludes mock bills to provide an accurate count of unprocessed, actual bills. ### System Enhancement Requests A prominent feature request was discussed to improve the usability and accuracy of internal tools. The current "product" field displayed in the system is not meaningful for operational prioritization, as customer tiers like "Gold" or "Platinum" do not consistently correlate with their service type (e.g., Bill Pay, AP). The proposal is to replace this field with the "service level" across the system, as this is the primary field used for prioritization and reporting. - **Need for better filtering and reporting:** The absence of a service-level filter makes it difficult to quickly answer critical questions, such as how many of the 3,000 live bills are for Bill Pay customers. This currently requires manually maintained and error-prone lists of customers, which becomes unsustainable as the customer base grows. - **Impact on operational efficiency:** The lack of this filter has led to reporting inaccuracies in the past, as team members can inadvertently miss customers when compiling numbers manually, highlighting the need for a more reliable, system-driven solution. ### Data Integrity and Other Investigations Several other data-related issues are under investigation to ensure the accuracy and reliability of the billing information. A known issue of double-counted usage is being looked into, with initial observations suggesting the problem may be isolated to the "distribution" component of bills and not the "supply" part. The team has received a detailed list of affected bill IDs to aid in the investigation. - **Clearing specific data errors:** There is an ongoing effort to address bills with specific errors related to "unit of measure," such as power factor and loads factor. While the volume of these errors is low, clearing them is considered a priority to improve overall data quality. - **Testing enrollment bill processing:** A question was raised about the readiness of the system to process "enrollment bills" through the DSS pipeline. It was determined that this specific workflow has not been formally tested, indicating it is not a near-term priority and its implementation complexity is not yet fully understood. ### Customer-Specific Workloads and Communications The team is preparing for an increased workload related to the customer "Victor," as a significant number of their bills with November due dates have been processed. This is expected to trigger inquiries from the customer, and the team is proactively aligning on how to respond. Furthermore, there is external pressure from the sales team regarding the development of a new "lab" or reporting dashboard ("LED") that accurately reflects processed "actuals." - **Managing external expectations:** There is a clear gap between the sales team's promises or expectations to customers and the current operational reality and development priorities. The development team's resources are not currently focused on building this requested dashboard, as they are occupied with more critical data processing tasks. - **Internal demo and testing support:** The team is also handling requests to load a limited number (e.g., 10) of accounts or bills for a broker named "Evolution" for demonstration purposes, balancing this ad-hoc support with their core responsibilities.

## Summary ### Invoice Processing and Migration Significant progress was made on processing and migrating invoice data, with a major automation script completed. A script for processing non-EDI invoices was successfully run for approximately 5,000 records, representing the bulk of the pending items. This script was enhanced with a checkpoint feature to remember its last execution point, ensuring efficiency and preventing duplicate work. The migration of the old SSRS lab report to Power BI is also nearing completion, with the final step being the replication of the exact view for querying in the new environment. The old report is already accessible within the Power BI report system. ### Power BI Report Development and Troubleshooting Active development and troubleshooting were conducted on several Power BI reports, with a focus on recreating existing system functionality and resolving access issues. The "System Status New" Power BI report was successfully recreated to show bill counts by workflow step. A persistent error when opening the report in Power BI services was identified and resolved during the meeting; the issue was related to the specific file version that had been published. The solution involved running and republishing the correct file from the Power BI Report Builder, after which the report loaded successfully. ### Data Archiving Strategy A strategy for archiving historical data was discussed to manage the large volume of records in the database. With approximately 6 to 7 million records marked with a "complete" status, some dating back to 2017, a decision was made on the scope of the archiving process. The plan is to archive all records from prior to the current year, while retaining the current year's data for troubleshooting and review of any failed system processes. The implementation of the archiving logic is pending final confirmation before the automated script is executed. ### System Status Report Enhancements The newly created "System Status New" report was reviewed, and a list of future enhancements was outlined to improve its clarity and usefulness. A key observation was made regarding the report's calculation of totals: the "Bills" column only shows pending bills and excludes those in a "ready to send" status, whereas the "Total" column includes all bills. Planned improvements include: - **Reordering and renaming columns:** To make the data presentation more intuitive and logical. - **Filtering out unassigned records:** Ensuring the view only includes builds associated with a specific client to maintain data relevance. - **Adding column descriptions or tooltips:** To provide clear definitions for each workflow step, aiding user comprehension. - **Enabling detailed drill-downs:** Investigating the possibility of expanding a customer row to view individual builds or batches for more granular analysis. ### Future Integrations and Access Preparations are underway for future system integrations and to resolve pending access requirements for the team. There is an intent to add new columns to the system status report for other business units like UBM, which are not currently included. A follow-up is required on a pending software license, as the vendor has not responded to recent emails. Securing this license is crucial for providing the team with the necessary access to the FDG connect system to proceed with upcoming work.

## Account Processing Logistics The meeting focused on establishing the procedures for handling non-EDI accounts, which involves a multi-step process for managing approximately 9,000 bills. The immediate plan is to begin processing these accounts by first storing the exported data locally. A dedicated SharePoint folder will be provided later for centralized uploads, to which access has already been granted. - **Batch Processing Strategy**: To ensure system stability and data accuracy, it was recommended to process the accounts in small batches of around 25 at a time. This cautious approach allows for verification that the correct number of folders is being generated and helps prevent any potential system failures during the bulk operation. - **Performance Monitoring**: A request was made to monitor how the processing script affects local machine performance, specifically regarding any throttling, to inform future scaling efforts. ## Automated Enrollment Ambiguity A significant portion of the discussion centered on a major uncertainty regarding the automated enrollment of new accounts. A question was raised about whether the system could automatically handle the setup for a vendor or client upon receiving their first invoice, but it was confirmed that this capability had never been developed or discussed. - **Functional Gap Identification**: The current system lacks the functionality to automatically create new accounts in the database when a bill from a previously unknown vendor is processed. This represents a substantial gap, as the work required to build this feature is estimated to be around 80% incomplete. - **Implication of Manual Work**: This gap means that for any new account encountered within the 9,000 bills, the setup will have to be performed manually, which is anticipated to be a significant and labor-intensive task. ## System Workflow for New Accounts The conversation explored what currently happens when a bill for a completely new account enters the system, revealing a lack of clarity on the exact workflow. It is believed that a new vendor or client is created in a system called PG Connect, but the specific process within other systems like DDS remains unclear. - **Need for Further Investigation**: The ambiguity surrounding the enrollment process for new customers was described as a "black box," highlighting a critical area that requires immediate follow-up and clarification with other team members. - **Potential System Usage**: There is a high degree of confidence (95%) that for secondary setups, a system called AKA Gas is being utilized, though this does not solve the primary issue of initial enrollment. ## Technical Setup and Access Practical steps were taken to facilitate the work, including the setup of a collaborative digital workspace. The necessary permissions were granted during the meeting to a specific folder, enabling the other participant to view and edit its contents. - **File Management Protocol**: The established procedure is to run the processing script, store the results locally initially, and then subsequently upload the files to the designated "non EDI setup build" folder in SharePoint once it is fully prepared.

## Summary ### Script Execution for Bill Retrieval The primary method for acquiring bill data involves running a script against a list of non-EDI accounts, though this process faces several immediate challenges. A key issue is the inability to implement a requested file naming convention that includes client details, as this requires substantial development work on the ingestion piece that cannot be prioritized at this time. While the script has been tested on small batches of around 100 accounts with manual verification, the output currently uses random serial numbers instead of descriptive names. Furthermore, a significant portion of the accounts, 563 out of the initial 7,412 non-EDI list, have image links that are "not available," which will require clarification from the client. ### Account Volume and Data Complexity The total scope of the project involves 8,823 meters, which are broken down into distinct processing categories. The non-EDI list, targeted for the initial script run, contains 7,412 accounts, while the EDI list has 2,457 accounts. A major complicating factor is that approximately 1,600 accounts have not generated an invoice since May, and their status as active or closed is unknown, creating a risk of setting up dormant or final-bill accounts in the platform. Reconciling the total counts is also a challenge, as the provided spreadsheet contains multiple account number columns, making it difficult to definitively identify EDI versus non-EDI accounts for accurate processing. ### Vendor Credentials and Onboarding Strategy A central dilemma is how to onboard the vast number of accounts without possessing the necessary utility website credentials, which the current vendor manages and cannot share due to confidentiality. This makes traditional credential-based onboarding impossible. A potential solution being explored is partnering with a third-party service, Arcadia, which specializes in programmatically retrieving bill data using credentials. However, the contract and security review process with Arcadia is still ongoing, with several stages remaining before they can be formally engaged. There is also a concern that setting up new credentials could disrupt the existing ones managed by the current vendor before the client has officially terminated that relationship. ### Project Timeline and Go-Live Dependencies The project timeline is under significant pressure, with an optimistic internal go-live target of April, which the client may find unacceptable. The delay is attributed to a late start and the recent receipt of the final account list. A critical dependency for go-live is the development of a payment file in both CSV and a specific text format that the client's system can ingest; without this, loading accounts is irrelevant. The client has a 60-day termination clause with their current vendor, and while there is willingness to request an extension, a firm go-live date cannot be committed to until the onboarding strategy is finalized and the payment file development is underway. ### Data Services and Initial Platform Population To unblock other workstreams and test the processes, a small batch of bills will be processed and pushed into the platform via Data Services. This initial load of 10-25 accounts, representing a mix of vendors and commodities, will serve multiple purposes: it will provide data for the payment file development, allow for testing the enrollment process, and give the client a tangible demonstration of progress. A decision on whether to scale this Data Services approach for the entire portfolio or rely on Arcadia is needed soon, as it has major implications for resource allocation and timeline. ### Reporting Requirements and Clarification The client has provided sample reports from their current vendor that need to be replicated. While initial conversations suggested a good mapping to existing platform capabilities, a detailed gap analysis is required. The reports in question include a billing details dump, an accruals report, and an approval file that involves cost apportionment across multiple general ledger accounts. The plan is to internally review these reports, document assumptions, and then schedule a dedicated call with the client to confirm the mappings and identify any missing data points before development begins. ### Arcadia Partnership and Vendor Analysis To evaluate Arcadia's capability to handle this volume, a proposal was made to share a sanitized vendor breakdown from the account list with them. This would allow Arcadia to assess the portfolio's composition by vendor and commodity and propose a concrete onboarding plan and timeline based on their experience and utility coverage. This engagement is seen as a critical test; if Arcadia can successfully manage this complex portfolio, it would validate their service for future engagements, but if they struggle, it would indicate that the internal process is more robust than anticipated.

## Summary The meeting focused on reconciling discrepancies between two separate lab reporting systems used for tracking late-arriving bills: the Data Services (DS) lab and the UBM lab. The primary goal discussed was the creation of a new, unified view that combines data from both systems to provide a single source of truth for internal visibility and action. ### The Core Problem: Disconnected Systems The fundamental issue is that the DS lab and UBM lab operate independently and are not synchronized, leading to conflicting data on bill status. The DS lab provides a live view of what bills have been captured by the download helper tool, while the UBM lab reflects the status of bills that have been fully processed and pushed into the UBM system for payment. This creates a lag and disconnect, where an account might appear as "late" in UBM even though the bill has already been received and is present in DS. ### Data Services (DS) Lab Report This system offers a real-time, collection-oriented view focused on the physical receipt of bills. Its methodology is based on the actual capture date of bills and uses historical data to project future bill arrivals. - **Live view of captured bills:** It shows what has been physically downloaded and is currently in the DS system's view. - **Calculation methodology:** The projected next received date is an estimate, calculated by comparing the last four bills for an account to establish an average cycle. - **Primary function:** Its main purpose is to guide the collection team in knowing which bills to download and process next. ### UBM Lab Report This system is designed for internal operational visibility and actionability within the UBM platform, focusing on the billing cycle and due dates for payment processing. It consolidates data at the billing account level, which is a combination of vendor and account number. - **Visibility and action within UBM:** It allows operators to see which accounts are within a certain number of days of their due date so they can take action, such as submitting mock bills. - **Calculation methodology:** It uses the invoice date and due date from processed bills to determine what is "late" or "missed," and it also allows for manual overrides to correct for anomalies in bill cycles. - **Primary function:** To enable operational teams to prioritize work and ensure timely payments by identifying gaps in the processed bill data. ### The Proposed Unified Solution The agreed-upon path forward is to develop a new report, likely in Power BI, that merges data from both the DS and UBM systems. This combined view is intended for internal use only, at least initially, to diagnose processing delays and improve operational efficiency. - **Combining data sets:** The new report will pull data from both DS and UBM, presenting key dates (like received date and invoice date) side-by-side with clear labels indicating their source system. - **Internal diagnostic tool:** The main value is in identifying discrepancies. For example, if a bill's received date in DS is recent but the corresponding processed date in UBM is old, it signals a bottleneck in the processing workflow that needs to be actioned. - **Phased implementation:** The initial goal is to establish a foundational view with the raw, combined data. More advanced features, like the custom calculations and summary pivots currently managed manually in an Excel sheet, will be considered in a second phase. ### Client-Facing Considerations and Risks The discussion highlighted the complexities and potential risks of exposing the combined data view to clients, leading to the decision to keep it internal for the time being. - **Current client access:** Some clients currently have admin access to the UBM lab data or receive daily reports derived from it, which already shows processing timelines. - **Risk of misinterpretation:** Exposing the DS receive date could lead clients to incorrectly calculate SLA breaches based on the time a bill sits in DS before being processed in UBM, even though the official SLA likely starts from the UBM loaded date. - **Long-term strategy:** The ideal scenario is that processing becomes so efficient that clients have no need for a late-arriving bills report. The internal combined view is a tool to help reach that level of performance. The future of granting clients direct admin access to such data was also questioned.

## Summary ### Project Charter and Executive Communication A key outcome from a recent executive meeting is the need to create a formal project charter and a subsequent summary for George. The charter must contain a clear problem statement that outlines the entire chain of processes, identifies what is broken, and connects proposed solutions to tangible business outcomes like avoiding missed payments or late fees. The summary for George should be factual and concise, consisting of a paragraph or a few bullets from each team lead explaining how this project will drive better results for their teams. The approach is to draft the charter first for team review and alignment, then use it as a basis for the executive email. ### Progress on Active Workstreams Several ongoing initiatives are tracking toward their scheduled completion dates, with significant progress reported across multiple teams. - **CSM Tool Access:** This initiative is nearly complete and on track for the end of November. The final steps involve determining where to place access links for customers and planning subsequent training for Customer Success Managers (CSMs) to utilize the new tool. - **Credential Synchronization:** The automated sync of credentials from Data Services (DS) to the UBM system is now operational, running on a weekly basis. Early feedback indicates that the newly available UBM credentials are working correctly for the Lab team. A remaining data integrity issue was identified where DS is not always synchronized with its source, Smartsheet, but this is acknowledged as a larger, separate process issue. - **Pay KD Files Update:** Development work for this update is scripted and has been prioritized. It is considered a relatively simple task with an expectation of completion and QA sign-off by the end of December. - **Invoice Processing:** Good progress has been made, and this workstream is on track for a November completion. The final task involves implementing and fine-tuning monitoring for the new processing system. - **Emergency Payments:** Phase one, which involved splitting the AP file, is complete. Work is now in progress on the AP file creation piece specifically for emergency payments, with an expected completion by the end of the month. ### Data Reporting and Credential Management Strategy The discussion focused on leveraging newly accurate data to improve long-term credential management and reporting, moving away from manual Smartsheet tracking. - **New Power BI Report for Credentials:** With accurate credential data now in UBM, the next step is to create a new Power BI report. This report would provide a comprehensive view of all billing accounts, the credentials available for them, and a clear list of what remains to be created or confirmed. - **Integrating MFA Status:** There is a need to incorporate Multi-Factor Authentication (MFA) requirements for vendor portals into this unified view. This would inform team members upfront if MFA is needed when accessing an account. - **Centralizing Onboarding Data:** A significant gap was identified in how bill access methods (portal, mail, email) decided during customer onboarding are tracked. Currently, this data resides in a transient onboarding sheet and is manually moved to Smartsheets, leading to visibility issues. The proposed solution is to define a single, reliable source-potentially by having CSMs upload a standardized file to HubSpot or using a fields in the Upsell API-where this data can be stored and then automatically fed into all relevant reports, including the new credential tracker. ### December Planning and Unplanned Work Looking ahead to December, the validation errors workstream was confirmed as the next priority. Additionally, the teams completed several unplanned, high-priority Power BI reports that addressed the project's core problems. It was agreed to retroactively add these as a completed "unplanned work" line item for November to fully capture the team's output and demonstrate problem-solving agility.

## Summary ### Output Service Development Progress Significant progress has been made on architecting the new output service, with a clear plan established for data flow through a queuing system. The development has advanced to the stage where multiple dedicated queues have been created to manage the workflow. The architecture is designed to process data in distinct stages: one queue for compiling the data, another for validating it, and a final one for outputting the processed information. While the foundational structure is in place, the actual implementation and coding for the logic within these individual queues is still in the early phases and requires further development. A dedicated follow-up discussion is planned to review this architecture in more detail and establish clear timelines for its completion. ### OpenAI Monitoring and Processing Pipeline An analysis of the OpenAI processing pipeline revealed an unusual operational pattern that requires further investigation. The monitoring dashboards show that the system actively processes bills for only half of the day, remaining idle for the remaining time. The initial hypothesis is that this is a positive sign, indicating that the pipeline is highly efficient and processes the entire daily queue quickly, leading to periods of inactivity because there is no backlog. However, an alternative possibility-that there is an underlying issue preventing continuous processing-must be ruled out. A thorough check of the POWER BI reports and the Azure IPS queue will be conducted to confirm that no data is stuck in the acquisition phase and to fully understand the pipeline's behavior. ### Infrastructure Monitoring with Grafana The adoption of Grafana for infrastructure monitoring is being aggressively expanded to provide greater visibility and operational intelligence across all services. The current focus is on extending Grafana's capabilities beyond the existing Microsoft queue visualizations. A key initiative is to integrate monitoring for the internal application queues, which will provide real-time insights into backlog and processing volumes. Furthermore, there is a strong push to leverage Grafana's full potential across the entire tech stack, with plans to implement tracking for application errors, user errors, and various processes. This comprehensive approach aims to create a centralized observability hub, making full use of the investment in this top-tier tool to improve system reliability and performance.

## Summary The meeting focused on critical challenges and strategic solutions for data processing and credential management, with a strong emphasis on preparing for the upcoming Arcadia integration. Discussions revolved around architectural improvements, data validation processes, and the need for a new, configurable data interpretation layer to solve persistent issues across platforms. ### Urgent Credential Management Challenges A pressing issue involves the synchronization and accuracy of client credentials across multiple systems, which is critical for the imminent Arcadia integration. The current process is fragmented, leading to outdated credentials that prevent accurate data pulls. - **System Synchronization Issues:** A recent attempt to sync the Data Services (DSS) credential table with the UBM platform revealed that the data was outdated compared to the primary source, Smartsheet. This creates a fundamental reliability problem for all downstream processes. - **Preparation for Arcadia:** Arcadia requires a single, accurate set of vendor credentials to pull data. A plan was discussed to query all existing systems (Smartsheet, DSS, UBM) for credentials, identify duplicates, and send the most likely accurate set to Arcadia by a target date of December 15th, accepting that some may be incorrect initially. - **Communication and Timeline Risks:** The Arcadia initiative has not yet been formally communicated to the Data Services team, creating a potential bottleneck. Furthermore, there is significant pressure from clients expecting a January go-live, but internal delays mean this timeline is already at risk, with the feasibility of a two-week turnaround by Arcadia being questioned. ### Strategic Arcadia Integration and Data Validation The integration with Arcadia is a pivotal project that requires a carefully phased approach to data ingestion and validation to ensure system stability and data accuracy. - **Dual-Path Data Ingestion Strategy:** A two or three-step ingestion process was proposed for Arcadia data to mitigate risk. This would start with processing Arcadia's PDFs through the existing DSS pipeline for a quick start, then gradually transitioning to using Arcadia's direct JSON output once its reliability is validated against the PDF-derived data. - **Proactive JSON Validation:** To preempt future processing errors, there is a plan to acquire sample PDFs and JSONs from Arcadia. These will be run through DSS to compare the outputs, identifying potential validation errors and mapping discrepancies before full-scale integration. - **Long-Term Architectural Goal:** The ultimate objective is to confidently parse and normalize JSON directly from Arcadia, attaching the original PDF for reference within the platform without initially pushing it through the PSS system, thereby streamlining the workflow. ### Architectural Overhaul: The Interpreter Concept A significant portion of the meeting was dedicated to designing a new, application-specific data enrichment layer, referred to as the "interpreter," to resolve recurring data mapping and validation issues. - **Solving Post-DSS Challenges:** The core problem identified is that DSS produces a standardized output, but applications like UBM and Carbon Accounting have unique, evolving logic requirements for mapping this data (e.g., matching bill IDs to virtual accounts using historical data). This logic is currently handled manually or through one-off scripts. - **Separation of Concerns:** The proposed "interpreter" would be a configurable service that sits between DSS and the application-specific import services. It would enrich the DSS output with application-specific logic (e.g., UBM Enrich, CA Enrich) without altering the raw, source-of-truth data from DSS. This ensures that different applications can have their own mapping rules without affecting each other. - **Modular Workflow Design:** This concept aligns with a broader architectural shift towards making DSS workflows more modular. The idea is to have different ingestion workflows for different data sources (like Arcadia), with the interpreter/enrichment layer acting as a plug-in module within those workflows to handle application-specific data massaging before the final import. ### System Reporting and Operational Visibility Updates were provided on efforts to improve operational reporting and visibility, which is crucial for managing client expectations and internal accountability. - **System Status Report Redesign:** A rebuild of the system status report is in progress, shifting the view from a "meters" basis to a more intuitive "builds" basis. This change aims to provide clearer insights into the pipeline's health and performance. - **Clarifying Ownership and Workflow:** The updated report will include clearer descriptions and column ordering to define ownership and workflow stages explicitly. The goal is to reduce the volume of manual, ad-hoc inquiries about build statuses and missed payments by providing a self-service, filtered view for customers and internal teams. - **Acknowledging Reporting Delays:** It was noted that while several new, urgent reports have been delivered, the originally promised reports for November and December are behind schedule. This will be communicated to stakeholders with the context that new priorities have displaced the original plan.

## Summary ### Mapping Location Error 3018 Resolution A new fuzzy matching logic has been implemented to resolve the 3018 mapping error for virtual accounts, aiming to automate the location mapping process in the future. The core strategy involves a two-step verification process to ensure accuracy: - **Fuzzy Matching with AI Embeddings:** The initial match uses AI and embeddings to calculate the similarity between service addresses and location addresses, successfully catching differences in abbreviations like "ST" for "Street". - **Number Verification Check:** A secondary, crucial check verifies that the first numbers (e.g., the street number) in the addresses also match, preventing incorrect mappings for locations on the same street but with different numbers. The immediate next step is a manual review of the generated file, which includes a column flagging matches where the first numbers do not align. The long-term goal is to integrate this refined logic directly into the platform to enable automatic mapping upon data ingestion, eliminating the need for manual intervention. ### Error Resolution Progress and Next Steps Significant progress has been made on resolving a series of other data errors, with several tasks nearing completion and one remaining in progress. - **Completed Tasks:** Files for error codes **2015**, **2016**, and **2024** have been prepared and are ready for review. These pertain to issues with prior balances and total charges. - **Pending Task:** The resolution for error **2027**, related to power factor and load factor, is still in progress and requires further work. Following the review and approval of the 3018 mapping file, the approved matches will be processed. A new, more current data backup will be used to generate the final mapping file to ensure data accuracy. ### Billing Overlap and Service Date Logic The meeting addressed a critical procedure for handling situations where a mock bill is followed by an actual bill with overlapping service dates and identical amounts. The agreed-upon logic is designed to prevent duplicate payments and ensure proper reconciliation. - **Cancellation Block Placement:** The cancellation bill block must be applied to the **actual bill** that follows the mock bill, not to the mock bill itself. This corrects a potential flaw in the initial approach that could have caused reconciliation issues. - **System Safeguard:** A critical system improvement was identified: bills that have already been sent for payment **must be locked** and should not be deletable. This prevents the accidental deletion of bills that are already in the payment processing pipeline. - **Potential for Duplicate Payments:** Concerns were raised about the possibility of duplicate payments occurring in the system, with at least one specific instance identified for further investigation. The effectiveness of the current query used to identify these overlapping bills was also questioned and will require further data verification. ### Access Requests A separate administrative action item was noted regarding user access. There are three pending requests for system access for new team members, which will be formally submitted and addressed in the upcoming development sprint.

## LED Report Process and Data Sources The meeting began with a detailed walkthrough of the process for generating the LED report, which is used for prioritizing mock bill submissions. The report is initially pulled from a specific system location, focusing on billing accounts with the "AP" or "bill pay" status. This data is then exported into a pre-formatted Excel template where calculations and summaries are performed. A critical dependency is that the customer package information in this report is fed from HubSpot, and its accuracy is paramount; inconsistencies arise when this data is not updated promptly by the CSMs. - **Data Pull and HubSpot Integration:** The process starts by exporting the "Last Bills by Billing Account" report, which relies on accurate package information from HubSpot: this is a known point of failure, as delays in HubSpot updates can lead to accounts being missed in the workflow. - **Excel Template and Prioritization:** The raw export is dropped into a specialized Excel template that summarizes accounts based on expected bill arrival and due dates: this summary is the primary tool for the team to prioritize which accounts to work on, with specific customers like Victra flagged as high priority. - **Platform Discrepancy:** A key distinction was clarified between the data in UBM (used for this report) and Data Services: the UBM data reflects when a bill physically arrives in the system, which is the trigger for the mock bill workflow, whereas Data Services uses a different logic, leading to potential discrepancies in what is considered "available." ## System Outage and Data Integrity Follow-up A system outage was acknowledged, which had generated some confusion internally due to a lack of clear communication. The team also discussed a backlog of data integrity issues, specifically concerning address mapping. A plan was established to review and approve updated files that would correct approximately 1,400 billing errors, with the expectation that this would resolve the integrity checks that had been flagged the previous day. ## Mock Bill Reconciliation and Cancellation Logic A significant portion of the discussion focused on the process and potential risks associated with mock bill reconciliation, especially concerning "cancellation bill blocks." The manual reconciliation process was confirmed, with a specific concern raised about a recent bulk processing effort that may have inadvertently sent through mock bills that should have been blocked. - **Manual Reconciliation Process:** The team manually identifies and archives bills with cancellation blocks, a process that was performed on a recent Friday, but there is lingering uncertainty about whether all ineligible bills were successfully filtered out. - **Cancellation Bill Block Mechanics:** The logic of a cancellation bill block was explained in detail: it is applied to the actual, follow-up bill and contains negative charges that negate the identical service period and amounts found on the previously paid mock bill, ensuring the net charge is zero and the bill is not sent for payment. - **Risk of Over-consolidation:** A concern was noted that if a cancellation block is incorrectly applied to a mock bill instead of the actual bill, it could distort financial analysis by masking the payment data. ## Priorities and Workflow Assignments The immediate priorities for the team were outlined, focusing on clearing the backlog of errors and continuing with standard client work. The primary goal is to approve the corrected data files to resolve the 1,400 billing errors. For client work, the team will concentrate on processing bills for Victra and Extension, with clear rules for each. - **Victra and Extension Processing:** For Victra, the team follows standard prioritization rules, while for Extension, the rule is to only pay current charges, removing any prior balances. Bills dated October 31st or earlier are to be flagged and moved to a projects queue. - **Error Code 5002 Handling:** Bills triggering error code 5002, which indicates total charges exceed a $24,000 threshold, require explicit approval from the client before they can be processed. - **Team Resources:** A new CSM has started and requires platform access, and the co-op team is being tasked with researching the top 30 utilities for the Victra client. ## Address Mapping Validation and Improvements The initial results from an automated address mapping process were reviewed. While the first pass using "first word match" and fuzzy logic showed promise, it was clear that manual validation is still necessary to ensure accuracy, especially for clients with complex addressing like multi-unit buildings. - **Initial Mapping Output:** The current export lists addresses where the first word of the location name is unique, providing a list of high-confidence matches, but this is just the first step. - **Need for Customer Context:** To facilitate faster and more accurate manual review, it was agreed that future exports must include the customer name alongside the address and customer number: this context is crucial for reviewers to spot potential mismatches that an algorithm might miss, such as matching different units in the same building for a client where that would be incorrect. - **Next Steps:** The plan is to refine the export to include customer names and continue refining the fuzzy logic, with a follow-up meeting scheduled to dive deeper into the mapping logic with the relevant developers.

## Summary ### File Exchange Updates and Power BI Report The file exchange changes have been successfully deployed to production, with the corresponding Power BI report also completed. The report requires minor updates, including the addition of a new column as requested. Once these final adjustments are made, the report will be shared in the designated team channel for review. ### Non-EDI Invoice Processing Script A script for processing non-EDI invoices is currently being refined. The primary focus is on modifying the script to generate PDF files named according to a specific format, incorporating the vendor name and account number. A secondary goal is to optimize the script to process invoices in batches of 100, which would significantly improve efficiency over the current method. However, a strategic decision was made to postpone these optimizations to prioritize other development tasks. The final destination for the generated PDFs is still to be confirmed. ### System Status Report Recreation A significant effort is underway to recreate the system status report, shifting its underlying metric from "meters" to "bills." The current logic for counting workflow steps was analyzed and found to be complex; for some steps, it counts unique bills, while for others, it pulls a meter count from the bills table. The initial objective is to rebuild the entire report to consistently use bill counts. Future enhancements will involve adding more status columns to provide a clearer and more detailed view of each bill's progress. A separate user interface for bills with unassigned clients was also proposed to better handle this data subset. ### Telerik UI Version Installation The team is facing a blocker regarding the installation of a specific older version (6.2.0) of Telerik UI for Blazor, which is required for the project. The current developer accounts only permit downloading the latest version. To resolve this, the team is actively seeking assistance through official support channels and internal contacts to obtain the necessary permissions or offline documentation for the required version. ### Future Work and Process Integration Looking ahead, the next major focus will be on the LED report. The plan is to begin by recreating this existing SSRS report within the Power BI environment. A key process improvement was highlighted: using the JIRA integration within Microsoft Teams to create and link issues directly from conversation threads. This will help maintain a clear audit trail of requests and their origins. The team was also instructed that all upcoming work, including the system status report, should be developed in Power BI for the time being, rather than as a web application, to streamline development.

## Summary The meeting primarily focused on the analysis and consolidation of invoice lifecycle reports from multiple systems to address late payment issues and improve tracking accuracy across platforms. A significant portion was dedicated to planning the creation of a combined report that would provide a complete view of the invoice journey. ### Invoice Lifecycle Reporting Status An update was provided on the current status of invoice lifecycle reports, confirming that one report had been completed and shared for review. The discussion centered around ensuring all necessary parties were aware of the completion while awaiting final feedback from an unavailable colleague. The report in question appears to be foundational for understanding the current state of invoice processing. ### Data Access and File Sharing Logistics Practical steps were taken to facilitate collaboration, including downloading and sharing a large Excel file containing data on items missing image links. This file, noted to be approximately 66 megabytes and containing around 500 entries, was identified as a point for future investigation. The team coordinated to ensure all members had access to the necessary data files through Slack, emphasizing the importance of having the underlying data available for manipulation and analysis. ### Combining Data Services and UBM Reports A core objective discussed was the integration of invoice lifecycle data from two primary systems: Data Services (DS) and UBM. The goal is to create a unified view that tracks an invoice from creation through to payment, identifying at which stage delays occur. Currently, these systems operate with different status definitions and tracking mechanisms, creating blind spots in the process. - **Understanding Delay Causes:** The combined report aims to pinpoint whether delays happen during data download, processing within DS, issue resolution in UBM, or due to client-side funding problems. This is crucial for accurately assigning responsibility for late fees. - **Business Imperative:** The urgency for this combined report is driven by a real-world incident where the company faced financial liability for late fees that were partially caused by a client's delayed funding, highlighting a critical gap in current tracking capabilities. ### Technical Implementation and Access Requirements The conversation detailed the technical and administrative steps required to build the combined report. A key hurdle identified was securing the appropriate data access permissions for the team member tasked with the integration. - **Platform Decision:** It was decided that the final combined report would likely reside within the UBM system to ensure broader accessibility for stakeholders, including other teams who would need to view the data without facing access barriers. - **Access Coordination:** A plan was formulated to contact system administrators and DevOps personnel to grant the necessary access privileges to the underlying UBM databases, not just the pre-built Power BI reports. ### Next Steps and Immediate Actions The meeting concluded with a clear action plan to advance the project. A message will be sent to the relevant system owners to request data access, enabling the immediate start of work on the combined report. The team committed to a follow-up discussion to review progress and refine the approach based on the accessed data. The assigned individual will begin familiarizing themselves with the UBM data structure to expedite the development of the combined reporting view.

## Report Requirements for Abhinavan The meeting focused on clarifying the specific data and details needed for a report requested by Abhinavan, which centers on processed invoice information rather than forecasts. Key elements include tracking invoice dates, due dates, and lateness metrics to provide insights into client payment behaviors. - **Invoice processing details**: The report should capture data from downloaded processed invoices, including the invoice date and due date, to calculate how many days late payments are, which helps in identifying delays and improving cash flow management. - **Client-specific insights**: Information must be organized by client account, enabling a granular view of payment patterns and potential issues per client, which supports targeted follow-ups and relationship management. - **Exclusion of forecast data**: Unlike other reports, this does not involve projected units or expected due dates, emphasizing actual historical data for accuracy in assessing current performance. ## Distinction from Lab Reports A clear differentiation was made between the invoice report and lab reports, with the latter focusing on forecasted metrics rather than actual processed data. This distinction ensures that the right type of analysis is applied for decision-making. - **Lab report purpose**: Lab reports provide forecasts on expected units and due dates, serving as a predictive tool for planning and resource allocation, whereas the invoice report is retrospective and based on real transaction data. - **Focus on current performance**: The discussion highlighted that Abhinavan's request is specifically about analyzing existing invoices for lateness and processing timelines, which aligns with operational reviews rather than forward-looking strategies. - **Clarification from previous mentions**: It was noted that while lab reports had been discussed earlier for forecast-related insights, the current priority is on actionable data from processed invoices to address immediate concerns. ## Implementation and Task Assignment Actions were defined to execute the report creation, with a focus on task tracking and completion to ensure timely delivery. - **Task creation and tracking**: A task will be created in a management system (e.g., MGR) to formalize the work, providing a clear timeline and accountability for producing the invoice report, which streamlines project management. - **Resource readiness**: Confirmation was given that all necessary data and tools are available to generate the report, minimizing potential delays and ensuring a smooth implementation process. - **Progress updates**: Regular communication will be maintained to report on task completion, allowing for adjustments and ensuring alignment with stakeholder expectations. ## Future Discussions and Access The need for additional conversations was identified, particularly regarding lab report access or related systems, to address unresolved questions. - **Upcoming dialogue on lab reports**: A separate discussion is planned to cover aspects of lab reports, such as access permissions or data retrieval methods, which could complement the current invoice analysis. - **Meeting rescheduling**: While a previous meeting was canceled, a new one will be set up to dive deeper into lab-related topics, ensuring that all report types are adequately addressed in future collaborations. - **Integration of insights**: These discussions aim to bridge gaps between forecast and actual data, potentially enhancing overall reporting accuracy and utility for stakeholders. ## Meeting Logistics and Follow-up Logistical aspects of the meeting were briefly addressed, including cancellations and plans for future interactions to maintain momentum. - **Cancellation acknowledgment**: The meeting that was canceled did not hinder progress, as key decisions were made in this session, demonstrating flexibility in adapting to scheduling changes. - **Scheduling forward steps**: Intentions to set up another meeting at a later time were confirmed, emphasizing continuous engagement to tackle pending items and ensure all report requirements are met efficiently.

## Summary The meeting served as an introduction and deep-dive into the two primary products within the Navigator platform: **Utility Bill Management (UBM)** and **Carbon Accounting**. The discussion centered on understanding the products, their target audiences, current marketing challenges, and opportunities for enhancing product communication and promotion. ### Product Overview and Team Introductions The session began with introductions from the product team members, who provided background on their roles and the products they oversee. The **Utility Bill Management (UBM)** platform is a tool that helps customers manage utility bill payments and analyze utility spend across multiple sites. The **Carbon Accounting** application enables commercial and industrial customers to measure their emissions, set sustainability goals, and track their progress. ### Target Personas and Use Cases A clear distinction was drawn between the typical users of each product, highlighting that they are usually different individuals within the same organization. The **Carbon Accounting** persona is often a sustainability director or manager focused on calculating, reporting, and meeting greenhouse gas emission targets. In contrast, the **UBM** persona is typically an energy manager, facility manager, or procurement specialist whose primary concern is the operational task of paying bills on time, ensuring accuracy, and gaining visibility into utility spending. ### Industry Focus and Customer Pain Points The discussion revealed how the adoption of each product is influenced by different industry dynamics and customer priorities. **Carbon Accounting** sees traction in sectors like food and heavy industrials, where companies face pressure from large partners like Walmart or Amazon to report emissions, and from large enterprises like Comcast or Pepsi that have public, C-suite mandated sustainability targets to uphold. Conversely, **UBM** is most successfully sold to **multi-site customers** with complex utility bill management needs, where the value proposition is a tangible reduction in operational expenses (OPEX) by identifying overpayments and avoiding late fees. ### Current Feature Release and Communication Strategy The product teams operate on a roughly **quarterly release cadence** for new features, though these are often enhancements to existing functionality rather than entirely new products. The current communication strategy for announcing these updates was detailed: - **Carbon Accounting** utilizes an internal and customer-facing process involving an **email template with GIFs and links** to a dedicated support article that explains the new feature. - A significant challenge identified is the need to develop a cohesive strategy for communicating product updates across different customer segments, particularly distinguishing between standalone Navigator clients and those who are retail power/gas customers now gaining access via the CEP (Constellation Energy Platform) integration. ### Marketing and Promotion Opportunities Several key opportunities for marketing to better support the products were explored: - **Website Enhancements:** A strong desire was expressed to create a **public-facing "Release Notes" or "Updates" page** on the website, similar to competitors like Watershed, to showcase new features and build credibility. - **Webinars:** There is a significant opportunity to develop a webinar program, both live and on-demand, to educate potential customers. This could include partnering with existing industry vendors and leveraging webinars for **content syndication** to generate leads. - **Lead Nurturing:** The idea of creating an **email sign-up on the website** for potential customers to stay informed about Navigator platform updates was proposed as a way to build a marketing database. - **Sales Enablement:** Ensuring that internal sales teams, including Vendor Managers (VMs), are fully aware of new features and equipped with the right messaging to promote them effectively was highlighted as a critical need. ### Competitor Analysis and Future Collaboration The team analyzed a competitor's website to understand best practices for presenting product updates. Looking ahead, there was agreement to **align product and marketing roadmaps** for the upcoming year to identify quick wins and ensure marketing strategies are prepared for upcoming product launches and initiatives.

## Database Cleanup Progress Significant progress has been made on cleaning up the DB2 column, with the team focusing on a conservative and methodical approach. The work has involved bypassing problematic areas to make headway, and the majority of the remaining work is now concentrated in the "unmapped bucket." A new logic is being developed to resolve these unmapped entries, but the team is proceeding cautiously after discovering some initial flaws. The goal is to resolve a high percentage (90%+) of these entries reliably, rather than pushing a fix that only handles a small portion. Historically, a customer-by-customer review via spreadsheet was sometimes more effective for ensuring logical sense, and the current strategy involves reviewing the most frequent issues and tackling them systematically. ## Lab Report Integration Initiative A key priority is the creation of a combined lab report view that unifies data from different sources, specifically Data Services (DS) and UBM. Historically, the team moved away from using the Data Services report in favor of the UBM one, but this has created challenges as the data does not always match. The immediate plan is to schedule a meeting with the primary experts, Tim and Afton, to align on the correct data source and logic. This unification is critical because discrepancies between the two reports indicate underlying data problems that need to be resolved. ## Operational Challenges and Process Adjustments The meeting highlighted several ongoing operational hurdles and the need for short-term manual fixes. A new, streamlined approval process is being established for these fixes, involving a small group to review and sign off on changes to ensure compliance, especially with an upcoming compliance season. The manual processes, particularly for the lab report, have been time-consuming and difficult to automate, with an estimated 50% of the work requiring human intervention. The team is also dealing with onboarding delays for new personnel, such as a new CSM who has received equipment but is waiting for a laptop, which is slowing down the delegation of tasks. ## Transitioning Work to the DSS Platform A major strategic goal discussed is the transition of operational work from the legacy DDS system to the new DSS platform. There is a pressing need for at least one operator to begin working directly within DSS to provide feedback and help build out its functionality. Currently, there are hundreds of bills in DSS that require pre-audit, and the team cannot effectively address the system's shortcomings without real-world usage. The plan is to encourage Afton to take on this role, as she has shown interest in learning the new system and has been asking for fixes. The transition will be gradual, focusing on moving what can be handled in DSS to reduce the manual load in DDS, even if it's a small percentage at a time. The ultimate objective is to reduce dependency on the legacy system, though it is acknowledged that some complex tasks will remain in DDS for the foreseeable future. ## Strategic Alignment and Weekly Planning To improve coordination, a recurring meeting will be established with Data Services, specifically involving Afton, to align on weekly priorities. This is necessary because there is currently no formal process for setting these priorities, leading to potential misalignment and delays. The goal is to create a consistent feedback loop where the operations team can communicate its needs to the development team, ensuring that necessary features for DSS are built. This regular communication is seen as vital for making steady progress on the transition and for managing the backlog of work effectively.

## Summary The meeting primarily focused on reviewing the current technical design for the Navigator project, with the goal of achieving alignment and ensuring it adheres to organizational standards before proceeding. Key discussion points revolved around validating the overall design, addressing specific non-standard components, and resolving several outstanding technical questions. ### Design Review and Alignment The core objective was to confirm that the proposed design is acceptable and compliant with security and infrastructure standards, assuming all components are technically feasible. - **General Design Approval:** The design was presented as the latest iteration, with the explicit goal of reaching a state that can be considered the final "home" for the Navigator project. - **Compliance with Standards:** A significant part of the discussion involved ensuring the design fits within the organization's security and environment standards, with an acknowledgment that some items would require documentation as exceptions. ### Documented Exceptions and Non-Standard Components It was acknowledged that the current design includes elements that do not perfectly align with standard practices, and a plan was formulated to manage these deviations. - **Reporting Access Exception:** A specific exception for reporting access was identified and agreed upon. The plan is to formally document this deviation and accept it for the purposes of this specific project. - **Tracking Deviations:** The team emphasized the importance of tracking these non-standard items to maintain oversight and accountability for the design decisions. ### Access and Feedback on Design Documents A practical hurdle involved accessing the latest design documents, which momentarily slowed the review process. - **Access Issues:** Immediate access to the shared design document was not available for all participants, requiring a request for permissions to be submitted during the call. - **Incorporation of Feedback:** It was noted that previous feedback had been provided on the design, with the expectation that it would be incorporated, though a final review of the updated document was pending for some attendees. ### Outstanding Technical Questions Two significant technical questions from a previous meeting were revisited, as they remained unresolved and critical for the final design. - **Scheduled Process Implementation:** The design's suggestion to use a Logic App for running scheduled reports from Okta was flagged as a potential issue. The concern is that this service may not be supported within the organization's standard infrastructure, prompting a discussion on alternative methods like cron jobs or other approved scheduling mechanisms. - **Integration Runtime VM for Power BI:** The purpose and necessity of an "Integration Runtime VM" shown in the diagram were unclear to several participants. This component is apparently related to enabling a Power BI integration with the project's database, but the specific connection method and its justification required further investigation. ### Path Forward and Next Steps The conversation concluded by outlining the immediate next steps to resolve the open items and solidify the design. - **Follow-up on Technical Questions:** The team committed to following up on the two main technical questions regarding the Logic App and the Integration Runtime VM to determine viable, standards-compliant solutions. - **Operational Guidance:** Once the design is approved, the plan is to provide the application team with a clear set of operational guidelines and runbooks, as this environment is new to them. - **Best Practices Review:** It was noted that a separate review of best practices for the platform-as-a-service (PaaS) constructs used in the application is also pending.

## Summary The meeting focused on addressing critical issues within the Data Services System (DSS) and its interaction with the legacy system (DDIS), with the primary goal of streamlining workflows and reducing manual intervention. Discussions revolved around specific error types, output failures, and proposed solutions to enhance system efficiency and data integrity. ### DSS Audit Queue and Error Handling The DSS audit queue is designed to flag bills requiring operator intervention, but several improvements were identified to make it more effective. The system currently halts bills with validation errors, such as invalid units of measure or service item descriptions, but the process could be optimized by redirecting certain errors automatically. - **Redirecting unit of measure errors to Account Setup:** This would leverage existing vendor and account-level notes stored in DDIS, allowing for faster resolution without manual operator searches in DSS. - **Addressing invalid observation types:** A recurring issue was identified where DSS sometimes creates its own, invalid observation types (e.g., "non fuel charge charge") instead of using the correct, system-recognized ones (e.g., "charge PR"). These errors are not always visible to the team until the bill fails later in the process. - **Enhancing communication with notes:** When bills are rerouted from DSS to other workflows like Account Setup, it was requested that a note be automatically appended explaining the reason for the rerouting. This would prevent confusion and save time for operators who currently have to investigate the cause manually. - **Rerouting logic for complex bills:** The logic for handling bills over six pages was discussed. Currently, these should be kicked out of DSS, but they are sometimes automatically picked up again, creating a loop. A proposal was made to send any bill with an existing client, vendor, and account number directly to the data audit queue instead. ### Output Service and Data Capture Issues Significant problems were reported with the output service, where data captured in DSS leads to failures when sent to the downstream UBM system. These issues often result in entire batches being rejected, necessitating manual reprocessing of all bills in the batch. - **Broken batches from blank meter lines:** A major cause of batch failures occurs with deregulated accounts and zero-usage bills. The system captures service dates on the supply meter but no usage or charges, resulting in a blank line on the output file that the UBM system cannot ingest. - **Re-emergence of a previously fixed issue:** This problem with supply meters had been resolved but has recently resurfaced, leading to a high volume of failed batches, including for new clients, indicating a regression in the system. - **Proposed solution of splitting batches:** To mitigate the impact, it was suggested that batches be broken into individual bills for output. This would ensure that only the problematic bill fails, rather than causing the entire batch to be rejected. ### Observation Type and Data Integrity Problems Beyond the output service, critical data integrity issues were highlighted where observation types and units of measure are being incorrectly altered during processing, leading to bills getting stuck. - **Blank or incorrect observation types:** Bills are being captured and sent to "ready to send" with blank observation types or observation types that do not exist in the system, forcing teams to manually pull them back and investigate. - **Incorrect unit of measure assignment:** A specific issue was described where the unit of measure on a default meter is changed to dollar signs, creating a cost line with no usage data. This also causes bills to fail downstream. - **Manual workaround and its limitations:** The current fix for these data issues involves manually using the "clear data" button, which reverts the units of measure and allows for reprocessing. However, this is a time-consuming and reactive solution that highlights a need for a more robust fix within DSS. ### Proposed System Improvements and Next Steps The discussion concluded with a focus on short-term fixes and longer-term system enhancements to address the root causes of these recurring problems. - **Short-term data routing with context:** An immediate action item is to configure DSS to push bills with specific errors, like unit of measure issues, to DDIS (Account Setup). Crucially, this will include sending detailed notes that identify the problematic meter by commodity type and meter number, along with the specific error message. - **Targeting key pain points:** The team committed to investigating several high-priority issues, including blank observation types, the "do not use" meter list, and the root cause of the broken batches from blank supply meter lines. - **Long-term vision for DSS:** The ultimate goal is to fully defang the legacy output service by having DSS handle output natively, thereby eliminating reliance on the legacy system and its associated failure points. Ensuring the DSS pre-audit queue is effective is a critical step toward this goal.

## Summary This meeting centered on addressing critical issues with a billing report system following the departure of a key team member. The discussion focused on understanding the current workflow, identifying data accuracy problems, and determining the necessary steps to create a reliable stopgap solution for customers. ### Purpose of the Billing Report The primary function of the report is to identify bills that are imminently due but are not yet present within the UBM system. It projects the next expected invoice and due dates based on the most recent bill information available in UBM for a given billing account, which is a combination of vendor and clean account number. The system is designed to flag accounts where a payment is expected soon, triggering a specific internal process. ### Data Accuracy and Processing Concerns A significant challenge identified is the report's reliance on data within UBM, which does not account for bills stuck in external processing stages or those not yet collected from vendor portals. The accuracy of the report has been compromised because it previously benefited from a human element that manually verified and corrected data, a step that is now missing. This has created a gap in ensuring customers have a clear and accurate view of their invoice status. ### The Lab Team's Workflow and Responsibilities A dedicated team, referred to as the "lab," is responsible for acting on the report's alerts. Their core task involves finding due amounts on customer portals and submitting mock bills for payment to prevent missed deadlines. This is a straightforward process designed to be executed without requiring deep system expertise. Furthermore, this team plays a crucial role in identifying data discrepancies during their review, such as discovering closed accounts or new account numbers, which they flag for administrative follow-up. ### Issues with Account Status Filtering A specific technical problem was highlighted concerning the filtering of open and closed accounts. A miscommunication in the report's filter logic has resulted in closed accounts appearing on the actionable list. The intended filter was for the billing account status, but it was incorrectly applied to the virtual account data. This forces the lab team to manually filter out accounts that are already known to be closed, adding an unnecessary step and potential for error to their workflow. ### Systemic Challenges and Next Steps The conversation concluded that the problems are multifaceted, involving both the report's configuration and potential underlying issues in the broader billing system. The core question is whether to fix the existing report to make it more helpful, resolve a deeper system issue that would consequently fix the report, or completely rethink the report's purpose and design. The immediate plan is to implement a short-term stopgap, but a more comprehensive solution is required to address the root causes of the data synchronization and accuracy challenges.

## Summary The meeting focused on identifying and analyzing the various methods operators use to upload invoices, with the primary goal of determining which methods are currently being tracked and which are not. The discussion centered on creating a comprehensive plan to implement tracking for all identified upload channels. ### Current Tracking Status The meeting began by establishing a baseline of the current invoice upload tracking capabilities. It was confirmed that only one method is actively being tracked at present. - **Web Downloads in FTG Connect:** This is the sole method where the upload of individual bills is currently being tracked by the system. ### Identified Untracked Upload Methods A significant portion of the conversation was dedicated to listing and understanding the invoice upload methods that currently lack tracking. Several key channels were identified as gaps in the current monitoring system. - **File Exchange in FTG Connect:** This method allows users to upload multiple invoices at once and is a notable gap in tracking that needs to be addressed. - **Direct DSS Upload:** Uploading invoices directly through the DSS (Data Submission System) interface is another common method that is not currently tracked. - **FTP Share/File Host:** Invoices submitted via an FTP (File Transfer Protocol) share or file host are processed by a "File Watcher" system, which currently attributes the uploads generically and does not track the specific user. - **Email Import:** Invoices received via email are also processed by the "File Watcher," resulting in a similar lack of user-specific tracking data. ### Implementation Considerations and Challenges The discussion then moved to the practical aspects and potential obstacles involved in implementing tracking for the untracked methods. The ease of implementation and the challenge of user attribution were key points. - **Attribution Complexity for Automated Methods:** A significant challenge identified is attributing uploads from automated sources like the FTP share and email imports. These are currently flagged under a generic "File Watcher" name, making it difficult to identify the actual operator responsible for the invoice. - **Varying Levels of Implementation Effort:** The team assessed that implementing tracking for the **File Exchange in FTG Connect** would be a relatively straightforward task. Similarly, tracking for **email imports** was considered feasible by potentially linking uploads to the sender's email address. ### Next Steps and Recommendations To move forward systematically, a clear action plan was formulated to address the tracking gaps. The approach involves breaking down the work into manageable tasks. - **Creation of Discrete Development Tickets:** It was decided to create separate, specific tickets for each untracked upload method: one for the File Exchange, one for the FTP share, one for DSS uploads, and one for email imports. This will allow the engineering team to address each channel methodically. - **Prioritization of the Easiest Solution:** The team plans to start implementation immediately with the method deemed the easiest to track-**File Exchange in FTG Connect**-to deliver a quick win and establish tracking for a bulk upload channel. - **Interim User Guidance:** A potential short-term recommendation is to advise users who need to perform bulk uploads to utilize the File Exchange method in FTG Connect, as it will be the first to have tracking capabilities restored.

## Customer The customer operates within accounts payable and utility bill management, relying on automated systems to process and pay a high volume of invoices for multiple clients. Their role involves ensuring payments are made on time to avoid late fees, which requires clear visibility into the entire payment lifecycle, from invoice ingestion to the final funding of payments by clients. Their background suggests a deep operational involvement in troubleshooting payment discrepancies and managing client expectations regarding payment performance. ## Success The most significant success identified is the development of a **manual workaround process** to create a daily "missing bills" report. This custom report was engineered to provide clients with a more digestible and actionable view of overdue payments than the standard, system-generated lab report. Despite being a manual and labor-intensive process, this solution has become critical for maintaining a dialogue with key clients, offering them a semblance of control and visibility into payment statuses that the core platform currently lacks. It serves as a vital stopgap for customer communication and trust-building. ## Challenge The single biggest challenge is a **profound lack of data visibility and system reliability**, creating a cascade of operational issues. A critical data field-the date a client funds a payment-is not being correctly pulled from the payment processor's API into internal reporting tools. This missing data point makes it impossible to determine responsibility for late fees, as there is no way to distinguish between delays caused by internal processing and those caused by the client's own funding timeline. Furthermore, the primary internal tool for identifying overdue bills, the "lab report," is fundamentally untrustworthy. Its inaccuracies force teams to rely on inefficient, manual workarounds and vendor-based bill pulling instead of a targeted, priority-driven approach, leading to missed payments and eroding client confidence. ## Goals The customer's objectives are centered on achieving clarity, accuracy, and efficiency in their bill pay operations. Their key goals are: - **Gain Clear Visibility into Payment Funding:** The foremost goal is to have the "funded date" from the payment processor reliably integrated into their dashboard and reports. This is essential for accurately assigning responsibility for late fees and defending against erroneous client claims. - **Establish a Trustworthy Missing Bills Report:** They need to either fix the existing lab report or build a new, accurate query that reliably identifies which bills are genuinely missing and require immediate action. This report is crucial for both internal operations and client-facing communications. - **Automate and Eliminate Manual Workarounds:** A core goal is to move away from fragile, manual reporting processes. The aim is to have system-driven, automated solutions that are scalable and reliable, freeing up valuable resources from daily firefighting. - **Enable Efficient Dispute Resolution:** They require readily available data to provide "ammunition" for customer success teams, allowing them to have factual conversations with clients about late payment responsibilities, thereby protecting revenue and managing relationships. - **Rethink the Core Bill Acquisition Process:** Ultimately, there is a goal to fundamentally reassess and improve the entire process of identifying and acquiring bills, moving beyond a system that perpetuates uncertainty and requires constant manual intervention.

## **Summary** The meeting primarily focused on significant challenges and unresolved questions regarding the development of custom reports for a client, Simon. A central theme was the gap between the client's expectations, established during the sales process, and the current state of requirements gathering and development. The team lacks the detailed specifications needed to begin building the reports, leading to a strategy session on how to proactively gather the necessary information and reset timelines. ### **Core Challenge: Delayed Custom Reports** The team is behind on developing several custom reports promised to the client, with a major issue being the lack of clear, field-level specifications. The client's expectation was that work would begin shortly after the contract was signed in July, but development could not start without detailed requirements that have not yet been provided. This has created a risk to the project timeline and client satisfaction. ### **Analysis of the Required Report Deliverables** The discussion identified four key reporting deliverables expected by the client. However, the exact nature and data sources for some remain ambiguous. - **AP (Accounts Payable) Files:** This is the highest priority and consists of two formats: a text file (TXT) and an Excel file (XLS). While some initial testing has occurred, development is stalled because the mapping of each column in the client's example files to specific data fields within the team's platform (UBM) is undefined. - **CET File:** This report appears to be similar to an accrual report but includes additional columns for taxes and late charges. Similar to the AP files, the source of the data for these specific columns is unknown. - **Bill Details Report:** This is understood to be a replication of a very detailed report from the client's previous provider (NG), containing comprehensive invoice information. The team is confident in their ability to build a report of this nature but requires clarity on the specific data mappings. ### **The Critical Block: Unclear Data Mapping and System Configuration** A significant portion of the meeting was dedicated to the fundamental blocker: the team does not know how to populate the data for the reports. The client has provided example files but no "translation key" for their data fields. - **Field Mapping Unknowns:** For nearly every column in the provided report examples, it is unclear what the corresponding data attribute is within the team's system. For instance, a "Vendor Name" column could be a standard field or require a custom vendor attribute, and this distinction drastically changes the development approach. - **Dependency on Client Setup:** The reports cannot be finalized until the client's account, locations, and vendors are fully configured within the platform with the correct attributes. The team cannot make assumptions about these configurations and requires explicit direction from the client. - **GL Allocation Complexity:** The reports appear to require General Ledger (GL) allocation data, a feature that was not fully developed at the time of the sale. While the platform can now handle this, it introduces another layer of complexity that needs to be precisely defined by the client. ### **Onboarding Complications and Data Integrity** A separate but related issue concerns the data provided for onboarding the client's accounts. The team is struggling with an inconsistent account list where it is difficult to programmatically distinguish between EDI and non-EDI accounts, and some accounts are missing essential bill image links. This onboarding delay has a cascading effect, as the reports depend on this data being correctly ingested and structured within the system. ### **Path Forward and Strategic Resolution** The team concluded that a reactive approach is no longer viable and agreed on a multi-step, proactive strategy to gain control of the situation. - **Internal Alignment:** The immediate next step is an internal meeting to consolidate all existing information from the sales process and document a precise list of known requirements versus open questions. The goal is to avoid approaching the client with a "blank sheet of paper." - **Engage Client Leadership:** The team plans to schedule a meeting with the client's main point of contact, Drew, to realign on expectations, clarify the history of commitments, and identify the correct individuals on the client's side who can provide the missing field definitions and mapping. - **Reset Development Timeline:** A clear, new timeline for report development will be established only after the complete set of requirements is gathered and validated. The team emphasized that they cannot commit to deadlines while fundamental questions about the data remain unanswered. - **Process Improvement:** A broader concern was raised about the need for a better handoff process from sales to delivery to prevent similar situations in the future, where custom work is promised without a clear mechanism for requirement gathering post-contract signing.

## Summary ### Current Bill Processing Status and Data Volume The meeting opened with a discussion on the current state of bill processing, revealing a significant volume of active cases. After filtering out mock data, the team is working with a dataset of **2,657 bills** from both the "build pay" and "AP" categories. A new "processing times details report" is now the primary tool for the team to work from, serving as a crucial stopgap measure to help focus efforts on legitimate, non-mock bills. ### Challenges with Mock Data and Account Freezes A major operational challenge identified is the prevalence of mock bills and the subsequent freezing of user accounts. When a mock bill is processed, it often freezes the associated account, requiring manual intervention to unfreeze it once the actual bill arrives. This has created a significant bottleneck. The team highlighted the need for a mass unfreeze utility or loader, as they currently lack the permissions to perform this action themselves and must rely on a specific individual (Ruben) to execute these changes. The situation is particularly acute with a specific new customer, Ascension, where all accounts were frozen pending balance reviews. ### Process Improvements and Automation Opportunities The conversation centered on identifying areas for process improvement and potential automation. A key request was for access to existing guides on how operators handle errors within the system (UDM). This would serve a dual purpose: helping to understand current procedures and identifying tasks that could be automated. The team is actively seeking ways to reduce noise in the system, such as by filtering bills by vendor to exclude certain cases and by having team members pre-identify accounts that are safe to unfreeze. ### Compliance and Audit Preparedness Significant concerns were raised regarding compliance, specifically related to an upcoming SOC audit. The team expressed apprehension about passing the next review cycle, citing a lack of evidence for some actions and historical instances of bills not being actioned for months. To address this moving forward, a new approval process has been established for certain fixes, requiring sign-off from designated team members. All related communication and tracking are now being centralized into a single channel ("UBM daily fixes") to ensure a proper audit trail and simplify future compliance reporting. ### Strategic Decisions on Bill Resolution A critical strategic discussion took place regarding the prioritization of bill payments versus perfect data integrity. Due to pressure to avoid service disconnections and get payments out the door, a decision was made to force some bills with minor data verification issues through the system. This approach acknowledges that it will likely create more work later, requiring extensive research and look-back to answer questions about potential double payments or other discrepancies. The team recognizes this trade-off, accepting that back-end reconciliation efforts will increase in the next 15-30 days in exchange for ensuring timely payments now.

## Daily Charges and Bill Resolution The meeting focused on the daily monitoring and resolution of total charges, with an emphasis on ensuring that all bills are properly handled and updated. A shared sheet was referenced as the primary tool for tracking these charges, allowing team members to quickly access necessary information without repeated inquiries. However, it was noted that the total charges daily resolve process might already be functional, but further verification is required. - **Review of total charges**: The current system involves checking a shared sheet daily to monitor charges, but there was uncertainty about whether the resolution process is fully operational, prompting a need for data validation. - **Bill count and historical handling**: There are 102 bills that need attention, and historically, initial phases were managed by specific individuals, but going forward, a more structured approval process is necessary to maintain compliance. ## Approval Process for Bill Edits To streamline bill edits and ensure compliance with SOC processes, a new approval workflow was established using a dedicated group in Microsoft Teams. This approach centralizes the approval process, requiring sign-off from key stakeholders before any changes are made to the bills. - **Centralized approval group**: A chat group involving Tim, Tara, and others will be used to approve daily changes made by the team, ensuring that all edits are reviewed and authorized to avoid future compliance issues. - **Handling bill downloads**: While files can be downloaded from Teams, it was acknowledged that this process can be cumbersome, so the group will serve as a hub for sharing and approving lists of bills that require fixes. ## Fixing Past Due Amounts Progress was reported on addressing past due amounts, with a recent list of 25 bills successfully fixed. The team emphasized the importance of continuing this effort to maintain financial accuracy and resolve errors promptly. - **Recent fixes and file sharing**: A file sent the previous day contained 25 bills that were corrected, highlighting the ongoing effort to tackle past due amounts and ensure data integrity. - **Interim logic clarity**: The logic for handling these fixes-prioritizing first, second, and then last steps-was confirmed to be clear, although it had not been implemented yet due to other priorities. ## Work Progress and Priorities The discussion highlighted current work priorities, including the focus on processing bills for immediate payment files and addressing any backlog. It was noted that while some tasks are clear, resource constraints have delayed progress on certain items. - **Payment file processing**: Attention was given to processing bills for Victor to include them in today's payment file, demonstrating a shift in focus to urgent financial tasks. - **Delayed interim logic implementation**: Although the interim logic for bill fixes is understood, it hasn't been acted upon yet, as efforts were redirected to more pressing issues like fixing specific bills overnight. ## Data Integrity and Verification Issues Concerns were raised about increasing numbers in data verification and integrity check statuses, indicating potential issues with bill data that need investigation. The team discussed methods for monitoring these metrics and identifying root causes. - **Monitoring integrity checks**: It was explained that integrity check statuses can be filtered in the system to view live builds, but the rising numbers in data verification 1 and 2 suggest underlying problems that require further analysis. - **Plans for investigation**: The team plans to double-check the data and share updated files if numbers change, with a commitment to ongoing monitoring and collaboration to resolve these integrity issues efficiently.

## Summary ### Power BI Access and Licensing Access to Power BI was successfully provisioned for key team members, marking a significant step forward in data reporting capabilities. The necessary licenses have been acquired and assigned, enabling the team to begin working with the platform. The focus now shifts to ensuring the correct administrative access levels are granted so that team members can not only view reports but also examine the underlying data sources and structures. This foundational work is critical for the team to become self-sufficient in creating and modifying reports. ### Auto-Archiving Feature Development Substantial progress was made on the auto-archiving functionality, a feature designed to improve data organization and system performance. The core user interface element for this feature has been completed, with the "show/hide" button being dynamically renamed to "archive" across the application, pulling its label directly from the Cosmos database. The next development phase involves creating and implementing a background job that will automatically archive records meeting specific criteria: a workflow status and a build status both marked as "complete" for a duration of 30 days. This duration is considered a starting point and may be adjusted to 14 days in the future based on system performance and user needs. ### Performance Optimization for Legacy System Queries A significant technical challenge was identified concerning the performance of data filters that query the legacy system. While most filters operate without issue, applying a filter for the "complete" status results in timeouts and bad request errors due to the immense volume of historical data in the legacy database. The current method requires fetching all records that match the filter from the legacy system before cross-referencing them with other systems, a process that is not feasible for large datasets. The team is actively exploring optimization strategies, including the possibility of changing how certain status values are sourced to reduce the dependency on the legacy system for these complex, cross-system queries. ### System Status Reporting Initiative A high-priority initiative is underway to replicate and understand the existing "System Status New" report. The goal is to empower the team to build and maintain such reports independently. To achieve this, team members are being equipped with the necessary tools and access, including the Power BI Report Builder, which allows for the download and inspection of report definition files. Understanding the underlying data is a key focus, with team members connecting to the legacy SQL database to examine the specific stored procedures and views that power the report. This deep dive is essential for replicating the report's functionality and ensuring the team has full ownership over its data reporting tools. ### Data Source Analysis and Access Management A major part of the meeting was dedicated to the practical steps of accessing and analyzing the data sources for reports. The team confirmed that the "System Status New" report is a paginated report that draws its data primarily from the legacy database via specific stored procedures. Gaining the correct administrative access to Power BI was a key hurdle that was overcome, allowing team members to download the report files and connect directly to the underlying SQL Server. This hands-on access is vital for the team to trace the origin of each data field and understand the complete data pipeline from the database to the final report output.

## Summary ### New Task Assignments Three new tickets have been created and assigned, with clear instructions and resources provided for their completion. - **Power BI Report Recreation**: The first and highest priority task involves recreating an existing Power BI report. Comprehensive details have been provided in Jira, supplemented by an overview video to assist with the task. To facilitate this work, direct contact with colleagues in Romania has been authorized for real-time assistance during their business day. - **Additional Assigned Tasks**: Two other tickets have also been assigned and are considered clear and ready for work to begin. These tasks are available in the "to do" column and are expected to provide sufficient workload. - **Telerik License Status**: A Telerik license is still being procured and is not yet available for use. This is noted as an upcoming resource, but its current unavailability is not expected to impede progress on the newly assigned work.

## Summary ### Introduction to the Power BI Report The meeting centered on the analysis and understanding of a specific Power BI report named "system status dash new report," which is accessible through the data services portal. The primary objective is to gain a comprehensive understanding of this report's data structure and to identify areas for enhancement, particularly concerning the visibility of client information for certain bills. The report is a critical tool for monitoring system status and contains multiple data views that require detailed investigation. ### Understanding the Report's Data Structure: Bills vs. Meters A fundamental concept discussed was the distinction between "bills" and "meters" within the system's data model. A bill is a primary entity that can contain one or multiple meters, which act as the fundamental building blocks of a bill. For instance, a single bill might be composed of several individual meter entries. This relationship is crucial because the current "system status dash new report" presents data from two different perspectives: one view is based on meters, and another is based on bills. This results in a discrepancy in counts; for example, a sample view showed 20 bills but 92,104 meters, clearly illustrating that meters are a more granular and numerous subset of the bill data. ### Objectives for Report Analysis and Enhancement The analysis has several key goals. The immediate task is to thoroughly investigate the existing report to understand the meaning and purpose of each data column. Following this understanding, the next step is to recreate the current meter-based view from the perspective of bills, which will likely involve a significant reorganization of the data columns. Furthermore, there are plans to potentially expand upon these columns as their functions become clearer, with guidance provided throughout this process. ### Addressing the Issue of "Unknown" Bills A significant data visibility issue was identified concerning bills with unknown client information. Currently, there are bills in the system for which the client name is not known, and this critical information is not displayed anywhere in the existing report. This lack of visibility can cause bills to become stuck in various stages of the data workflow-such as in DSS (Data Staging Services) or the "audit data" stage-without being easily traceable because they lack an associated vendor or client name. A key initiative is to find a way to surface these "unknown" bills within the report to improve tracking and resolution. ### Clarifying the Data Workflow The discussion touched upon the ideal data workflow, although it was noted that the current sequence in the report is not entirely accurate or sequential. The intended flow begins with **data acquisition**, where data first enters the system. From there, it progresses to **DSS**, which is likely a data processing or staging layer. After DSS, data either moves to **account setup** or to **setup audit** if manual review is required. Finally, data that is cleared moves to a **ready to send** status. It is during the early stages of this workflow, such as in data acquisition or DSS, that vendor and client names should ideally be identified, but this is not always happening as intended. ### Access and Resources for the Task To carry out this analysis, access to specific tools and data sources is required. If there are any issues accessing the Power BI service itself, the appropriate contacts are Mercha and Andre on Slack. Mercha can assist with Power BI licensing access, while Andre can provide the necessary permissions to access the underlying data that feeds into the "system status dash new report." Ensuring this access is a prerequisite for beginning the investigative work.

## Summary ### Business Growth and Sales Initiatives A significant focus is on accelerating revenue growth for the currently low-revenue company, with a major emphasis on sales activities. A recent large sales opportunity was pursued, which resulted in a promising long-term lead: a potential client expressed strong interest but is locked into an existing two-year partnership. They have invited further discussions and suggested that if certain additional capabilities were developed, they could start a partnership immediately. This underscores the critical importance of securing customer contracts, as all other efforts are deemed secondary until sales are finalized. ### Operational and Technical Challenges The discussion reveals several ongoing operational hurdles that are impacting productivity and project timelines. - **Internal Process Bottlenecks**: Significant time is being lost due to internal processes and bureaucratic hurdles, particularly when trying to start new tasks or procure resources. - **Power BI Licensing**: A specific, immediate challenge involved purchasing new Power BI licenses, which was complicated by an expired session and a request for a purchase order number that was not typically required. A workaround was successfully implemented to complete the purchase. - **Third-Party Vendor Management**: For additional licenses, coordination with an external vendor (Telark) is required. It was confirmed that these licenses are managed separately from the main corporate IT environment and do not require additional internal approvals. ### Infrastructure and Security Migration A complex and delayed project to migrate the technology infrastructure to the main corporate environment ("Constellation") was discussed in detail. The goal is to establish a fully functional development environment where applications, databases, and queries can operate seamlessly. - **Current State and Delays**: The migration is far behind schedule, with an estimated completion now targeted for May. The process has been slowed by unforeseen technical complications, such as separate virtual networks and a multi-layered approval process for tickets. - **Security Concerns**: The current setup of the web application firewall (WAF) is largely ineffective; it merely proxies encrypted traffic without inspecting it, which negates its primary security purpose. This raises questions about the value of the current security implementation. - **Deployment Strategy**: The plan is to first get the basic infrastructure approved by security and other teams. Only after this foundation is stable will engineers be able to begin deploying and testing code in the new environment, which is a prerequisite for meaningful development progress. ### Audit and Compliance Demands The company is facing pressure from both internal and external audits, which is consuming considerable resources. - **SOC 1 Audit**: The company is undergoing a SOC 1 audit, where auditors are demanding 100% proof for randomly selected invoices, creating a significant administrative burden. - **SOC 2 Commitments**: There is external customer pressure to achieve SOC 2 compliance, a promise that was made approximately a year ago. However, given the current workload and delays in other projects, achieving SOC 2 before the onboarding of a major new client at the start of Q2 is considered highly unlikely. ### Project Onboarding and Resource Allocation The onboarding process for new clients is a major pain point, directly linked to resource constraints and strategic decisions made in the past. - **History of the Data Services Solution (DSS)**: The transition to an AI-powered solution for data processing was initiated after promising early tests in February. The original plan involved a slow, methodical testing phase with dedicated personnel. However, this plan was derailed when the dedicated tester was reassigned, and other teams were too busy to assist. This led to a decision to push the system to "production" without adequate testing, which has contributed to ongoing instability. - **Resource Scarcity**: Historically, requests for additional engineering resources to handle the onboarding workload were frequently denied. This forced a shift in development philosophy from building robust, long-term solutions to creating quick, short-term fixes just to stay afloat. The current situation involves "pulling" resources from other projects without formal assignment to manage the workload. - **Business Strategy Tension**: A fundamental conflict exists between the need to invest in scaling the business (a "growth investment" phase typical of VC-backed companies) and the current reality of "pinching pennies." This creates unrealistic expectations about the pace of development and the stability of the platform. ### Financial and Administrative Tasks A brief mention was made of ongoing financial administrative duties, specifically the management of expense reports through the SAP Concur system. It was confirmed that this task is being handled, though the specific individual responsible was not identified during the conversation.

## Summary The meeting focused on resolving a critical data discrepancy in client billing records, specifically concerning the "prior bill pass due amount" column that was causing system errors. A detailed, step-by-step analysis was conducted to identify the correct methodology for clearing these erroneous balances. ### Identifying the Core Data Discrepancy The primary objective was to pinpoint which data columns to compare in order to validate and subsequently clear out incorrect prior bill pass due amounts. The initial approach of subtracting the "prior bill amount paid" from the "prior bill amount due" was found to be flawed, as it primarily resulted in zero values and did not address the actual problem causing the system errors. ### Clarifying the Correct Column Comparison A pivotal clarification was made regarding the data relationship: the correct comparison should be between the **"Prior Bill Amount Paid"** (what was actually paid on the last bill) and the **"Past Due Amount"** on the *current* bill. This is because the error stems from the system treating an already-paid amount from a previous bill as still being overdue on the current bill. - **Correcting the comparison logic:** The initial logic was comparing data from the *same* historical bill, which was not useful. The solution involves comparing data from two different sources: the payment record of the last bill against the outstanding balance field of the current bill. - **Defining the clearance action:** When these two values are equal, it indicates that the amount shown as "past due" on the current bill has, in fact, already been paid. Therefore, the "Past Due Amount" field (Column E in the spreadsheet) should be zeroed out. ### Data Validation and Refinement Process A rigorous process was undertaken to apply the new logic and filter the dataset for actionable items. The team moved from a theoretical discussion to practical implementation within the spreadsheet. - **Applying the new formula:** A new column was created to calculate the difference between "Prior Bill Amount Paid" (Column L) and "Past Due Amount" (Column E). - **Filtering for actionable items:** The dataset was then filtered to exclude non-bill-pay customers and to focus on records where the calculated difference was zero, confirming they were candidates for clearance. This refined the list from a seemingly small number of entries to a more substantial and accurate count of **145 records** requiring correction. ### Finalizing the Action Plan and Next Steps With the correct methodology established and validated, a clear path forward was defined. The refined and filtered list of 145 client records will be sent for processing to clear the identified prior bill pass due amounts, thereby resolving the underlying system errors.

## Summary The meeting focused on strategic architectural planning for the Data Services System (DSS), primarily addressing the need to decouple client-specific logic to enable broader, multi-tenant usage across different applications. ### Core Problem: Coupled Logic and Scalability The central issue identified is that the current DSS contains a significant amount of logic that is specific to a single client, UBM. This design prevents the system from being easily opened up to other internal applications, such as Carbon Counting and Glimpse, or to external customers in the future. The goal is to separate this UBM-specific logic to create a more generic, scalable data extraction and processing service. ### Proposed Solution: An Interpreter Layer and Workflow Orchestration The proposed solution involves creating a flexible "interpreter" layer that can handle client-specific data massaging and translation. A key concept discussed was modeling this system using configurable "puzzle pieces" or building blocks that can be assembled into different workflows. - **Workflow-Based Architecture:** The idea is to move away from a single, fixed processing pipeline in DSS and instead support multiple, parallel workflows. Each workflow would be a unique sequence of processing steps tailored for a specific client or use case. - **Leveraging Existing DSS Foundation:** It was strongly suggested that this new capability should be built *within* the existing DSS framework rather than as a standalone service. This approach would leverage the existing asynchronous task processing, queuing systems, and infrastructure, making it faster to implement than creating an entirely new service from scratch. ### Technical Implementation and Scalability The discussion delved into how the proposed architecture would function and scale to meet future demands. - **Handling Multiple Inputs:** The system is envisioned to accept data from various sources, not just PDFs. It could also consume the structured JSON output from other processes, providing flexibility in how data is ingested. - **Scalability and Capacity Management:** A primary concern is scaling the AI processing capacity, currently a constraint due to OpenAI token limits. A proposed solution is to create separate workflows that utilize different AI models (e.g., GPT-3 vs. GPT-5), as each model has its own independent capacity pool, effectively multiplying available processing power. - **Priority and Queue Management:** The existing queuing system in DSS can be enhanced to manage workload priorities. The concept involves a "priority bucket" system that processes tasks based on predefined rules, ensuring high-priority work (like bill pay) is handled before lower-priority tasks. This would be a one-time setup per client or application. ### Onboarding and External Access The conversation covered the practicalities of allowing other applications and potential external users to consume the service. - **API and Documentation:** For internal Constellation Navigator applications, access would be provided through a curated API (e.g., a specific Swagger definition). It was noted that comprehensive onboarding documentation and a formalized API agreement, including error codes, need to be developed. - **Security and Multi-tenancy:** A significant point was that the current DSS UI lacks multi-tenancy, meaning all users can see all data. For true external access, a new, secure API gateway would be required to ensure data isolation, where external parties can only access and query their own data. ### Strategic Alignment and Next Steps The group aligned on the strategic direction and outlined preliminary next steps for the initiative. - **Path Forward:** The consensus was to proceed with enhancing DSS to support multiple, configurable workflows. This is seen as a more efficient path than building a separate service, despite the acknowledged benefits of isolation. - **Initial Actions:** The immediate next step involves high-level planning for the refactoring effort required to introduce the multi-workflow concept into DSS. This will be followed by an analysis to identify and separate UBM-specific logic from the core data extraction logic. - **Long-term Vision:** The ultimate goal is to transform DSS into a centralized, scalable platform for data extraction that can serve a wide array of internal and external customers, with client-specific needs handled through customizable workflow pipelines.