--- title: "How a duplicate payment email led to Billing OS | Dagny" description: "How a duplicate QuickBooks payment email led to a semi-autonomous billing system, built with finance operators, Agentic Athletes, and forward-deployed engineers." canonical: "https://dagnylabs.ai/blog/how-a-duplicate-payment-email-led-to-billing-os" last-updated: "2026-10-25T13:46:10Z" --- # How a duplicate payment email led to Billing OS | Dagny [HTML page](/blog/how-a-duplicate-payment-email-led-to-billing-os) [All field notes](/blog) Field notes October 6, 2026 8 min read # How a duplicate payment email led to Billing OS How a duplicate QuickBooks payment email led to a semi-autonomous billing system, built with finance operators, Agentic Athletes, and forward-deployed engineers. Will Holtz Managing Partner Share [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fdagnylabs.ai%2Fblog%2Fhow-a-duplicate-payment-email-led-to-billing-os) [](https://x.com/intent/tweet?text=How%20a%20duplicate%20payment%20email%20led%20to%20Billing%20OS&url=https%3A%2F%2Fdagnylabs.ai%2Fblog%2Fhow-a-duplicate-payment-email-led-to-billing-os) On this page - [The pain and consequences](#the-pain-and-consequences) - [The tools in use](#the-tools-in-use) - [Where to start](#where-to-start) - [Specific vendor challenges](#specific-vendor-challenges) - [Bringing this all together with Agentic Athletes and FDEs](#bringing-this-all-together-with-agentic-athletes-and-fdes) - [The results](#the-results) - [The continued evolution](#the-continued-evolution) Many of the best solutions derive from the pain points that I’ve experienced time and time again. That’s why, when I received duplicate emails with QuickBooks payment links from a partner vendor, I could already sense that there was more to this than an errant duplicated message. I sent an unprompted message offering to talk with that vendor’s finance lead about some ways I had been able to offset the pains of invoicing with AI. A week later, I received a message asking if that offer still stood. Fast forward just a few weeks later, this same partner is now leveraging a semi-autonomous billing system in partnership with Dagny. Now let’s take a step back and see how this solution progressed. ## The pain and consequences Within all service-based businesses, there are early stages in which the founders set up preliminary systems and processes that unknowingly lead to significant operational ‘debt’ as the organization scales. This is through no fault of their own, as growing a new business always takes precedence over making sure each process is perfectly tuned. These problems typically persist until individuals hired to build better systems put a spotlight on them, or scaling makes them impossible to ignore. For billing, downstream operational challenges range from varying contract structures to manual invoicing and exception handling, and generally inconsistent products and services that make data unification difficult. Left unaddressed, the consequences can be late payments (and hence a working capital imbalance), time spent handling manual customer exceptions, and less time to focus on the higher-level strategic customer relationships that make these businesses unique. ## The tools in use The upside of the contracts and accounts receivable process is that the inputs and tools are fairly consistent. Most financial operators need: - A customer record (direct partner contacts, billing contacts) - A source system for billing (QuickBooks Online, Stripe, [Bill.com](http://Bill.com) ) - Contractual terms (services rendered, service periods) - Billing terms (net payment terms, discounts offered) - Exceptions (known context from the commercial and finance teams) - An approval process for billing and exception handling The challenges begin when the ways in which this data is collected and synchronized are inconsistent. And due to challenges in maintaining the various source systems, the operators become the unlucky beneficiaries of bad or incomplete data that can lead to firefighting with individual, important customers. ## Where to start The first question that is often asked is: knowing all these constraints, where should we begin? With this specific case, as with a majority of cases, we prefer to ask: where should we end? With billing and invoicing, the goal is to have customer invoices generated on a predetermined schedule, with consistent and accurate information that allows customers to pay properly and on time. This sounds easy, but in practice various tools need to work in concert to supply the information for invoice generation. For many, that process still consists of using standard, duplicated templates that become the responsibility of a finance lead each month. QBO is notoriously hard to navigate, and inserting highly customized data is even more difficult as customer needs evolve. ## Specific vendor challenges With this specific vendor, some customers are direct brands and others are agencies that manage media spend on behalf of multiple brands. Given that pricing is primarily determined by tracked spend, there is a specific need to transparently account for individual differences at both the advertiser and rolled-up customer level. And while QBO has a system for uploading invoices via CSV templates, handling this type of customer complexity, mixed with discounts, prepaid credits, currency differences, one-time sales and operations exceptions, and dynamic credit notes, is no easy task. The upside for this partner is that this data did exist, with spend tracked within their Snowflake warehouse, customer records that could be split at the advertiser level, and newly implemented Salesforce processes that had the prerequisite information for a unified customer profile. ## Bringing this all together with Agentic Athletes and FDEs Every practical agentic solution starts with high-quality data infrastructure and the context of how the data fits together for the end use cases. In this scenario, this meant first aggregating all the available information into a unique customer record: everything from invoice records and different code-based customer aliases across spending platforms to billing and account owner contacts, addresses, and contract notes. The organization also had unique commercial pods tied to accounts that needed to be aware of account health and exceptions. This is where having a technical background in data engineering serves the Dagny promise well, as what used to be a long, drawn-out process to set up a data warehouse now takes a matter of days with the right context. Just as importantly, I’ve been a CFO and operations lead for most of my career and had been building out agentic operational systems to solve these exact pain points before (even without the benefit of the best-in-class agentic engineering talent at Dagny!). That meant I already had a good handle on where the data lives in the source systems, how the approval and validation processes happen at the beginning of each month, and how exceptions can start to be standardized by cleaning up the data and setting up processes that keep future customizations from causing problems downstream. The flow between the agentic athlete and the forward-deployed engineer (FDE) went something like this: - The agentic athlete builds a v1 of the Billing OS based on the available data (in this case, source-of-truth exports). The FDE reviews the feature mockups and checks for any additional scoping needs, such as where the data lives. - Once source data access is granted, the agentic athlete confirms the necessary fields to generate customer profiles and invoices, working with the operators who know how the process actually runs. - The FDE takes that context and works back and forth with the agentic athlete and operators to harden the system, embedding validation while keeping the system flexible enough to handle real customer needs. - Together, we work through the exceptions, test the changes, and get operator feedback before standardizing the process going forward. And while I had intimate knowledge of these processes, coordination with the partner’s finance and data teams to keep figuring out where the operational gaps live is critical. The people using the system need to buy into the process, and their feedback needs to keep returning to what we build. ![Billing OS customer workspace with payment terms and team filtering, using fictional customer data.](/images/field-notes/billing-os-customers.webp) Customer workspace after operator feedback added payment terms and team filtering. Customer details and figures are fictional. In finance, the numbers have to match the source systems dollar for dollar. Historical invoice and product or service exceptions need to be recorded and remain auditable, even as we standardize the process going forward. Prepaid offsets and advertiser-specific invoice splits are good examples of details that need to carry through correctly. The real test comes on the 1st or 2nd of the month, when the operator starts invoicing actual customers. That’s when customer-specific misses show up, and we need to iterate quickly while testing the changes and keeping customer communications consistent with what each customer expects. This takes commercially minded engineers who understand why that flexibility matters. Reliable iteration also takes tests, versioning, an audit trail, and a way to roll back changes, so that solving one customer’s exception doesn’t put the rest of the system at unnecessary risk. No solution is perfect, and there will be constant iteration. That’s okay. A solid foundation gives us the flexibility to keep improving as real use reveals what we missed and what needs to change. ## The results We promised a working, end-to-end billing solution in less than two weeks, and we delivered. ![Billing OS invoice review in an archived build, using fictional customer data.](/images/field-notes/billing-os-invoice-review.webp) Invoice review in an archived build, with fictional customer data. By the walkthrough, the finance lead was already seeing the difference: “I'm so much further ahead than I thought we were going to be.” He put the outcome plainly: “I've solved the invoicing problem. I feel like I can hang my hat on that.” And he was clear about our contribution: “I just was explaining all of the problems, and you guys are the scientists behind fixing those problems.” Another core operations lead said the system had already saved him at least 40 hours in that invoicing cycle. There is no greater feeling than having an operator tell our team how useful these solutions are, how much time they save, and how much stress they take away. Operations is often a misunderstood and underinvested part of the organization, yet operations is absolutely critical for healthy scaling and, especially for service-based businesses, client satisfaction. ## The continued evolution The best part about a solution like this is that we can continue to iterate. As new operational and financial gaps show up, we can work with the operators to build a roadmap for where the product goes next, using infrastructure that is already in place. That foundation means the next build can be faster and less expensive because we’re not starting from scratch. Operators also become more familiar with how these processes work, how to give useful feedback, and how to test and iterate quickly. For this partner, the next steps we’re discussing include invoice tracking, overdue balances and discount eligibility, contract-to-billing flows, and more automation around accounts receivable and customer health checks. These are directions for continued development, with priorities shaped by real use and feedback. The same foundation gives us a way to support new product lines and markets, including separate accounting connections and additional currencies, so operations can keep up with the growing demands of the business. A lot of what we’ve built is deterministic: clear rules, validations, and repeatable workflows. We’re building that foundation with agentic best practices in mind, so agents can take on more of the routine work over time while financial operators keep the judgment and approvals. Everything starts with the foundation. The applications we build and the feedback we get allow us to keep delivering from there. On this page - [The pain and consequences](#the-pain-and-consequences) - [The tools in use](#the-tools-in-use) - [Where to start](#where-to-start) - [Specific vendor challenges](#specific-vendor-challenges) - [Bringing this all together with Agentic Athletes and FDEs](#bringing-this-all-together-with-agentic-athletes-and-fdes) - [The results](#the-results) - [The continued evolution](#the-continued-evolution) ## Field notes by email Receive new notes from Dagny. Newsletter signup is currently unavailable. ## More from the notebook - [How we work Oct 13, 2026 Rails behind Dagny’s Rails](/blog/rails-behind-dagnys-rails) - [Field notes Oct 6, 2026 How disagreement shapes our work at Dagny](/blog/how-disagreement-shapes-our-work-at-dagny) ## What’s the first workflow you’d fix? Tell us where your team gets stuck. We’ll discuss what a first build could look like. [Book a call](/book-a-call)