I Built a 24/7 Finance Analyst With Claude (Full Tutorial)

[00:00:00]I built a live AI FPNA analyst inside clawude live artifacts that continuously reads financial reports, operational data, treasury metrics, manufacturing performance, workforce planning, and even business emails to automatically explain what is happening inside the business and why. So instead of behaving like a static dashboard, the system stays connected to live business data, links operational activity directly into financial impact, identifies risks before they hit reporting cycles, and behaves more like a real finance intelligence environment than traditional reporting. The entire system runs across connected business sources in real time. So the analysis evolves as the underlying operational and financial data changes. as a quant and finance automation developer. I'm going to show you exactly how I built this unified FPNA environment inside Claude Live Artifacts. And if you want the prompts and the full project setup from this video, it's free in the community I have linked in the description below. So, for now, let's get into it. Before we build anything, I want to explain what live artifacts actually are because that distinction is what makes this project possible. A normal Claude artifact is something most people have seen. You ask Claude for a a dashboard or a document inside a conversation and then Claude generates it and the file sits beside the chat and you can iterate on it during that session but it essentially it's a snapshot. It doesn't stay connected to anything and it does not update when the underlying data changes.

[00:01:40]A live artifact inside coowork is built differently. It can stay connected to external sources. So things like a Google Drive folder or an Air Table base and Gmail, things like that. Now the metrics and the charts inside it then refresh when the source data changes. So the artifact reflects the current state of the business rather than just a frozen view that doesn't change. So the second thing that matters is what Claude can pull together when it builds a live artifact. Normal Claude outputs work from whatever is in the conversation at that moment. With a live artifact, Claude can reason across multiple connected sources during the build.

[00:02:27]structured financial data, operational planning assumptions and unstructured business communication and then bake that analysis into the environment itself. The multi-source reasoning is what gives the system its analytical depth from the very start. Now once it is built, the data layer stays connected and the values keep refreshing as the sources change. The analytical commentary written into the artifact reflects the picture Claude built it from. Connecting the sources. I open a new session inside Claude co-work and confirm that three sources are already connected. The Google Drive folder named as an example use case. Aurora Automotive Group holds the financial and operational backbone. things like monthly actuals, budgets, treasury reports, manufacturing data, supplier records, and executive commentary. The Air Table base holds the structured planning and the operational assumptions, including risk flags, scenario, inputs, and KPI targets. And the Gmail account holds the operational signal layer where supplier delays, overtime escalations, pricing pressure, and production updates show up as live business messages. Each source plays a different role inside the system. Drive is the historical and current financial reality. Air table is the forward-looking assumption layer. Gmail is the live operational signal layer that basically flows business events into financial implications before those events ever reach a reporting cycle. Now the prompt there are a few decisions inside it that shape what the system becomes and they are worth understanding before you build something like this yourself. The first decision is to frame the artifact as an FPNA analyst rather than a dashboard. Now that single framing shifts what the system prioritizes. So instead of defaulting toward chart generation, Claude shifts toward reasoning. It thinks about what drove the numbers, what operational conditions created the movement and what risks exist underneath the surface. The difference between an environment that displays financial data and one that explains it usually comes down to this framing. The second decision is to ask for one cohesive environment rather than separate mini tools. Real FPNA analysis is [music] interconnected. There's an analysis connects to cash flow. Operational issues connect to margins. Planning assumptions influence forecasting. Now, if those layers are all just fragmented into disconnected widgets, then the system can't reason across them. One unified environment is what allows the intelligence to work across the connected sources all at once. The third decision is to assign a clear purpose to each connected source. So Claude knows which system is the financial backbone, [music] which is the assumption layer and which is the operational signal feed. Now that is what stops the system from treating them as interchangeable.

[00:05:46]The fourth decision is not to prescribe the interface. If you describe the layout, the charts, the workflows, and every component in detail, you get a hardcoded demo back. Basically, letting Claude design the interface itself guided by the analytical role and the data available produces something that actually [music] fits the business content it was built for. Now, the prompt also tells the system to test calculations, [music] filters, and live behaviors before presenting the artifact, which pushes Claude into a validation mindset rather than a generationonly mindset when it is connecting to multiple life sources at once. How Claude builds the environment.

[00:06:28]Once the prompt runs, Claude does not start generating an interface. It moves into a discovery phase first where it reads through every connected source and tries to understand the business environment before building anything on top of it. It identifies the drive folder as the financial and operational backbone. It pulls the actuals and budget files. It opens the supplier and dealer data sets and then reads the treasury reports. Then it moves into air table to extract the assumption layer, the scenario records and the operational risk mapping. Then it scans Gmail and pulls operational threads tied to overtime, supplier delays, pricing pressure and production disruptions. Now what stands out here is that Claude does not summarize these sources separately.

[00:07:14]It starts building relationships between them. It is [music] connecting how operational events in Gmail might affect financial outcomes in the drive folder or how planning assumptions in air table should shape forecast interpretation and where contextual business activity ties back into reported numbers. Now very early in the process it explicitly states that it needs to retrieve specific numeric values from the actuals and budget files by parsing them through bash. Now that is a significant moment because it shows the system moving past surface level interpretation. It is pulling exact financial values directly so that the analysis stays mathematically grounded. The build then becomes increasingly datadriven. Claude reconciles revenue bridges, validates gross profit calculations, links operational events to EIT D exposure, and checks whether scenario assumptions match planning logic. It tests interactive navigation filters and chart relationships before finalizing anything. And only after the full environment behaves consistently does it register the system as [music] a persistent live artifact inside co-work.

[00:08:31]This sequence matters because it is how a real FPNA analyst would approach the same problem. Before [snorts] building reporting layers, an analyst reconciles source data, validates assumptions, identifies operational drivers, and connects business events to financial outcomes. The claw just follows the same workflow during the [music] build itself. Walking through the command center, the final environment is a connected intelligence system with seven analytical layers. Each one focused on a different operational domain, but all tied to the same financial backbone. The first layer is the executive pulse. This is the leadership facing command view that summarizes overall financial health while explaining [music] the operational conditions behind the numbers. At the top, Claude surfaces revenue, gross margin, EBIT, DA, net income, and net leverage against budget. And what makes this layer different from a normal KPI dashboard is that every metric is paired with the operational reasoning behind it. The revenue beat is tied to volume growth, pricing realization, and EV mix expansion. The margin improvement is tied to lower battery costs, freight normalization and premium mix. The leverage peak in August is tied to treasury pressure even and a recommendation to preclar debtf funded capeex until covenant headroom improves.

[00:10:03]Every KPI carries its own driver story.

[00:10:07]The various intelligence layer is built like a real bridge analysis. You can switch between revenue, EBIT, DA, COGS, and net income views and then compare actuals against either budget or the Q3 forecast. The revenue bridge decomposes the favorable variance into specific operational drivers, including volume recovery, EV mix shifts, pricing realization, FX headwinds, and regional softness. Each driver has its own commentary explaining why the movement happened and whether it is structural or just temporary. The monthly P&L underneath shows how performance evolved through the year and the regional and product line breakdown separate consolidated results into the segments that actually drive them. The revenue and margin driver section goes a bit deeper into the mechanics behind the financial results. So revenue growth is broken into its components. The distinction between what drove revenue and what drove margin is what makes the analysis actionable rather than just descriptive. A revenue beat driven by volume has different strategic implications than one driven by pricing execution or product mix. And the system makes that visible rather than just rolling everything into a single headline number. The manufacturing and supply chain layer tracks production operations across multiple plants.

[00:11:35]Utilization, output volumes, downtime events, supplier delays, and logistics costs are all present. And what matters about this section is how it connects into the financial environment rather than operating as [music] just a standalone operational report. A supply chain disruption does not just appear as an operational flag. It flows through to margin pressure and it shows up in the relevant financial sections as well. The operational and financial layers also inform each other throughout the system.

[00:12:05]The workforce section connects labor conditions into cost structure and profitability. Overtime levels, attrition, hiring gaps, and wage inflation are mapped against manufacturing throughput and ebit exposure. The system goes beyond tracking the metrics. When overtime runs significantly above budget across a set of plants, it identifies the affected facilities. It estimates the financial impact and then it links it back [music] to the margin picture. And that connection between workforce execution and financial outcome is something finance teams usually have to calculate and document separately. [snorts] And here it's just all built in. The treasury section tracks liquidity, leverage ratios, covenant headroom, debt structure, and capital deployment across the fiscal year. And one of the most valuable things this section does is surface the peak leverage point during the year alongside current [music] headroom. So that historical context matters for covenant monitoring. Knowing what leverage came close to the covenant cap during a specific period tells Treasury leadership where the sensitivity is and how much operational deterioration the balance sheet can absorb before financing risk increases.

[00:13:26]And that kind of forwardlooking awareness is what separates treasury monitoring from treasury reporting. The operational signals layer is the most advanced part of the system. So instead of waiting for month end reporting, it pulls signals directly from Gmail and translates them into forecast implications. An overtime escalation across three plants becomes an upward revision to labor cost growth assumptions. A North American pricing pressure thread becomes an increase in dealer incentive assumptions. A semiconductor delay in one of the European plants becomes a reduction in plant utilization assumptions for the coming quarter. Three active operational signals together represent roughly $95 million of full year 26 first half debit risk. And the system already separates managed exposures from unmanaged ones.

[00:14:21]Now what makes this layer matter is the operational or is the fact that operational events stop sitting in someone's inbox and they start moving directly into forecast assumptions.

[00:14:34][music] So supply delays, overtime spikes, pricing pressure, and production disruptions become quantified inputs to the financial model rather than just disconnected updates that someone has to manually translate later on. Modifying the source data. This is the part that proves the system is actually connected [music] rather than presenting fixed values. So I open the full year 2025 monthly financial actuals Google sheet directly the same file that artifacts is reading from and I changed the July and December revenue values inside the consolidated P&L section. The EVID da operating income tax expense and net income values update automatically because the sheets formulas carry through. Then I go back to the live artifact and click refresh.

[00:15:24]The first refresh does not pick up the changes because the synchronization layer is still processing the updated state in the background. So I wait a few moments and then I click refresh again and the new values now flow through. The KPI cards update the revenue trend chart redraws with the new July and December spikes. The artifact is responding to a change I made inside the source file, not to a prompt. I did not rebuild the dashboard. I did not regenerate any visuals. I just edited a Google sheet and the FPNA environment moved with it.

[00:16:01]Now what makes this powerful is that no automation infrastructure is involved.

[00:16:07]There is no Zapier flow. There's no make.com automation. There's no cloud database. There's no scheduled job pulling values into the dashboard. The live artifact itself is the connection layer. The finance team continues working inside the same Google Sheets they already use and the executive environment evolves alongside that work.

[00:16:32]So that's it. That's the full system.

[00:16:34]One prompt, three connected sources and then seven analytical layers and a live artifact that updates as the underlying business data updates. The Aurora command center is doing the work that normally lives across spreadsheets, ERP exports, planning models, treasury schedules, manufacturing trackers, and email threads. All of it collapsed into one continuously operating environment.

[00:17:01]Now, if you want the prompts and the full project setup from this video, it's in my free community which is linked in the description below. and I'll see you next time.