Testing Ling 3.0 Flash Fin’s API on Massive Spreadsheets and Real Financial Data

LLMs today are incredible for writing articles or generating code. But one area where I don’t see them get used often is finance. It’s just way too risky, I guess. A single hallucinated cell reference can cascade through an entire valuation sheet and destroy your discounted cash flow analysis.

Financial workflows leave little room for that kind of error. Misreading an accounting disclosure or using the wrong revenue denominator can change the conclusion even when the output looks convincing.

I wanted to see how a specialized model would handle these constraints. Instead of just running a few prompts in a chat window, I built a custom Next.js web application to test Ling 3.0 Flash Fin with sourced financial data, a browser workbook, and tools for reviewing financial disclosures.

Personally, I find this more useful than judging a model from a chat response alone. Having the numbers, charts, and source material beside the answer gives me something concrete to check.

This article is a breakdown of what the model actually is, how I wired up the application, and the results from three demonstration workflows.

Before I get into the details, here’s a demo of how each module works using the Ling 3 Flash Fin API:

What Is Ling 3 Flash Fin?

Ling 3.0 Flash Fin is a finance-focused model built through continued training of Ling-3.0-flash on financial data. Its stated use cases include financial research, reasoning across documents, valuation, and spreadsheet workflows. The official model card describes 124 billion total parameters with 5.1 billion activated parameters.

The model is competitive with both similarly sized models and substantially larger general-purpose models, with particular strength in source selection and tool-intensive financial tasks.

That made it an interesting candidate for this experiment. I wanted to see whether it could interpret financial categories, explain workbook updates, and recognize when a disclosure didn’t contain enough information to support a calculation.

I accessed the model through OpenRouter, using the model identifier inclusionai/ling-3.0-flash-fin:free. That's the model used throughout the application.

Ling-3.0-flash-Fin OpenRouter API. Image by Jim Clyde Monge

If you prefer local inference, the official checkpoint is available on Hugging Face, and there are community GGUF quantizations, including bartowski’s Ling-3.0-flash-Fin-GGUF. Running those requires suitable hardware and a compatible runtime.

For this project, I used the API. That kept the setup manageable and let me focus on the application. Requests in this version go to an external provider; I didn’t test local inference.

Let’s Talk About the API Access

Financial applications need to handle network errors and slow responses clearly. A request that times out shouldn’t leave a result panel looking as though an analysis succeeded.

I centralized the browser’s model requests in lib/openrouter.ts. Every request goes through the Next.js route at /api/openrouter, which attaches the authorization and attribution headers before contacting OpenRouter.

The browser calls the internal API route, keeping the OpenRouter key on the server.

Here is the core request setup, excerpted from the server route. The surrounding code validates the incoming request, checks whether the key is configured, and returns upstream errors to the browser:

// app/api/openrouter/route.ts — request setup excerpt
const apiKey = process.env.OPENROUTER_API_KEY;

const payload: Record<string, unknown> = {
  model: LING_MODEL_ID,
  messages,
  max_tokens: 16000,
  temperature: 0.2,
};

if (tools && Array.isArray(tools) && tools.length > 0) {
  payload.tools = tools;
  if (tool_choice) {
    payload.tool_choice = tool_choice;
  }
}

const openRouterResponse = await fetch(
  "https://openrouter.ai/api/v1/chat/completions",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
      "HTTP-Referer": req.headers.get("origin") || "http://localhost:3000",
      "X-Title": "Ling 3 Flash Fin Demo",
    },
    body: JSON.stringify(payload),
    signal: AbortSignal.timeout(110000),
  },
);

LING_MODEL_ID is set to inclusionai/ling-3.0-flash-fin:free.

The server request has a 110-second timeout, while the browser request has a 120-second timeout. Empty responses and completions cut short by the token limit produce errors rather than accepted analyses.

This gives the terminal a clear error state if a request takes too long or returns an incomplete response. It sounds like a small implementation detail, but I don’t want to wonder whether a financial explanation stopped halfway through.

How I Built a Web App With the API

I wanted this to feel like a real desktop financial terminal. I used Next.js 15 with the App Router alongside Tailwind CSS for styling and Recharts for the data visualizations.

Here’s the end-to-end system architecture in case any devs out there are interested:

Custom NextJS project for Lang 3 Flash Fin. Image by Jim Clyde Monge

The chart displays the supplied financial data, and the workbook runs its calculations in application code. Ling analyzes those inputs and requests supporting evidence through the research tools.

One of the most annoying parts of building AI user interfaces is handling unconstrained container growth. You send a prompt, and the model returns two thousand words of dense Markdown. The default web container stretches vertically and ruins your layout.

To fix this, I built a custom Markdown viewer component. Its rendering wrapper looks like this:

// components/MarkdownViewer.tsx — rendering excerpt
return (
  <div
    className={cn(
      "custom-scrollbar overflow-y-auto pr-2 text-xs leading-relaxed text-slate-200 font-sans select-text space-y-1",
      maxHeight,
      className
    )}
  >
    {elements}
  </div>
);

I paired this with a custom scrollbar design in my global CSS. The application constrains its height and lets long responses scroll internally. The workspace stays contained and feels like a native app.

I like having the analysis and the evidence visible at the same time. Scrolling back and forth through a long conversation makes it too easy to lose track of which number the model is discussing.

With the architecture in place, I ran the model through three distinct workflows to see where it would break.

Demo 1: Finance Report and Visualization

First up was financial report and disclosure analysis. Equity research footnotes contain multibillion-dollar nuances that can change how you interpret a company’s revenue.

I tested the model on NVIDIA, comparing Hyperscale with ACIE, which stands for AI Clouds, Industrial, and Enterprise.

The app uses a manually transcribed snapshot from NVIDIA’s Q2 FY2027 filing, reviewed on September 10, 2026. The chart and the model receive the same underlying figures. There’s no live web search in this module.

Query: Analyze NVIDIA growth drivers. Calculate Hyperscale and ACIE year-over-year growth and shares of Data Center revenue. Explain the recast and distinguish observed revenue growth from hypotheses about demand. What does this evidence not tell us about margins or end-customer concentration?

Demo 1: Finance Report and Visualization. Image by Jim Clyde Monge

There is an important reporting detail here. NVIDIA reclassified a customer from ACIE to Hyperscale in Q2 FY2027 and recast prior periods. To compare growth consistently, the app uses the historical figures presented on that same reporting basis.

This is important because a category can appear to grow simply because its definition changed. I wanted the comparison to reflect revenue growth across equivalent categories.

Here are the checked calculations from the test:

From FY26 Q2 to FY27 Q2, Hyperscale revenue grew 101.55%, while ACIE grew 138.14%. Data Center revenue increased 116.62%, so it more than doubled.

The category shares use Hyperscale plus ACIE as the Data Center denominator. Edge revenue sits outside that subtotal and is included in total company revenue.

ACIE’s share increased from 41.19% to 45.28% over the year. Both categories grew substantially, but ACIE grew faster on this recast basis.

I requested structured calculations through a submit_analysis function schema so the application could check the numbers before displaying them.

The app checks the returned periods, subtotals, shares, and growth rates against its own calculations. Incorrect or incomplete fields trigger a visible validation error. This function provides a structured output format for the analysis.

The interface displays checked calculations separately from the model’s interpretation, which still requires review.

Demo 1: Finance Report and Visualization. Image by Jim Clyde Monge

The supplied snapshot supports comparisons of revenue and category mix. It doesn’t establish category margins, individual customer concentration, or why demand changed. Those questions require additional evidence, even though the full filing contains information beyond the small table passed to Ling.

Revenue growth is observable here. An explanation involving pricing, product mix, or customer demand needs evidence of its own.

The right pane presents Hyperscale in green and ACIE in cyan using interactive Recharts bar charts. This lets me compare Ling’s explanation with the financial data alongside it.

Demo 2: Financial Modeling in a Browser Workbook

The second test combined application calculations with a model-generated workbook review.

I loaded an Alphabet 2026 Q2 revenue workbook into the application. It has three browser views: Summary, Q2 Actuals, and Projections. It contains seven revenue and hedging rows, with the calculations running directly in the browser.

Demo 2: Financial Modeling in Excel. Image by Jim Clyde Monge

The historical figures come from Alphabet’s 2025 annual revenue table, and the quarterly figures come from its Q2 2026 earnings release.

FY2024 revenue totals $350,018 million, FY2025 totals $402,836 million, and Q2 2026 totals $119,796 million. The quarterly release is unaudited.

The rows include Google Search & other, YouTube ads, Google Network, subscriptions/platforms/devices, Google Cloud, Other Bets, and hedging gains or losses. Including hedging is necessary to reconcile these categories to consolidated revenue.

Alphabet reports segment results as Google Services, Google Cloud, and Other Bets. Search, YouTube, Network, and subscriptions are components of Google Services. The workbook presents revenue categories that add up to the company’s total.

Clicking Execute Update & Review maps seven actual values into Summary. Application code recalculates the Summary total, seven Q3 scenario values, and the scenario total. Ling then receives the workbook data and explains the mapping and variances.

If the model request fails, the app reports that separately from the completed workbook update.

Demo 2: Financial Modeling in Excel. Image by Jim Clyde Monge

With the illustrative growth assumption set to 10%, the formulas are:

Q2 estimate = round(Q2 2025 actual × 1.10)
Variance = Q2 2026 actual − Q2 estimate
Q3 scenario = round(mapped Q2 2026 actual × 1.10)
Total = sum of all seven rows

The estimates totaled $106,070 million, producing a positive variance of $13,726 million against Q2 actual revenue. The rounded Q3 scenario values totaled $131,776 million.

Google Cloud had the largest positive variance at $9,782 million. Google Network and Other Bets had negative variances of $786 million and $28 million respectively. These are differences against an illustrative assumption, not surprises against analyst consensus.

The Q3 scenario applies the assumption quarter over quarter. It is a way to explore a possible outcome, rather than company guidance or an analyst forecast.

I like keeping the assumption visible in the interface. A projection can look surprisingly authoritative once it sits in a neatly formatted table, even when it comes from something as simple as applying 10% to the previous quarter.

Demo 2: Financial Modeling in Excel. Image by Jim Clyde Monge

Corporate financial models are networks of connected calculations. This small workbook demonstrates three of the operations involved:

1. Actuals mapping: Move sourced quarterly values into the active-period view.
2. Estimate replacement: Change the active values from an illustrative estimate to the corresponding actuals.
3. Dependency recalculation: Update totals and scenario values that depend on those inputs.

I was pretty satisfied with how this worked. The application handled the mappings and recalculations, while Ling supplied a review of the workbook and the assumptions behind it.

Demo 3: Financial Evidence Review

The final test was a tool-assisted financial research task using Spire Inc., the natural gas company listed on the NYSE as SR, with CIK 0001126956.

Spire classified its Marketing and Storage businesses as discontinued operations, as described in its July 2026 disclosure. I wanted to see whether Ling could identify those businesses from the supplied disclosures and explain what information was needed to rebuild historical continuing-operations earnings.

Demo 3: Financial Evidence Review. Image by Jim Clyde Monge

Notice the three-column technical implementation:

1. Tool-call terminal: Records model-requested read_filing calls, their source IDs, and completion or failure status. The count reflects the calls executed during the run.
2. Evidence viewer: Shows the text returned by each successful call, a source link, and whether the result is an offline summary or a live excerpt.
3. Model findings: Displays Ling’s analysis, its explanation of the accounting treatment, and any missing evidence needed for a calculation.

The browser orchestrates a bounded agent loop. It forwards model requests through the server proxy, dispatches requested source reads to /api/sec-edgar, and returns their results as tool messages. The loop allows up to six model turns and 12 source-tool calls before reporting an incomplete run.

For this sample, I selected the default offline mode. Ling requested both available sources, and the log recorded two completed calls. Each call returned a curated source summary for the model to read.

The summaries cover the July recast disclosure and relevant portions of Spire’s June 30, 2026 Form 10-Q. They establish the discontinued-operation classification but omit the numerical income and disposal-group tables.

Here’s the task I gave the model:

Query: For Spire Inc. (NYSE: SR), establish which businesses are discontinued and explain how to rebuild FY2025 continuing-operations earnings on the recast basis. Read both available sources. Calculate historical profit only if the source tables contain all required amounts, identify the exact period and units, and show the arithmetic. Otherwise identify the missing evidence.

Ling identified Storage and Marketing as discontinued operations. It also stated that the summaries lacked the figures needed to calculate historical profit.

Demo 3: Financial Evidence Review. Image by Jim Clyde Monge

A valid reconciliation would need consolidated net income and discontinued-operations income for the same entity, period, and after-tax basis. At that level, the relationship is:

Continuing-operations net income
    = Consolidated net income
    − Income from discontinued operations, net of tax

If discontinued operations reported a loss, subtracting that negative amount increases continuing-operations net income.

Continuing-operations net income is also different from EBIT or an adjusted non-GAAP measure. Sale proceeds alone can’t fill those gaps, and a calculation needs to use the financial measure requested.

This is why I wanted the evidence viewer in the middle of the screen. I want to be able to read what the model received before deciding whether its conclusion follows from it.

The application also has an optional live SEC mode. It requires a SEC_USER_AGENT value identifying the organization and contact email. The server fetches only the allowlisted filings and extracts bounded HTML text excerpts. It doesn't parse XBRL or read numbers embedded in slide images.

For the run shown here, I used offline summaries because live SEC requests from my environment returned HTTP 403. The result demonstrates source review and identification of missing evidence; calculating historical profit would require the numerical schedules as well.

By the way, I have open-sourced the project. The GitHub repository is here:

LingFinance

Why Should You Care?

If you build fintech applications or work in equity research, you already know the pain of using LLMs for math-heavy tasks.

A convincing explanation isn’t enough. Revenue needs to reconcile, spreadsheet assumptions need to be explicit, and accounting conclusions need to trace back to the right disclosures.

Ling 3 Flash Fin produced useful financial explanations and requested the source tools provided to it. The application made those results easier to inspect by placing the evidence, calculations, and commentary together.

To me, that is a practical starting point for financial AI: tasks small enough to check, with enough context for the model to contribute something useful.

That makes this approach worth testing for the repetitive parts of financial research. The calculations still need independent checks, and the interpretations still need review.

Final Thoughts

Alright, I hope you found this demo interesting and also learned how the Ling 3 Flash Fin API works.

Building this Next.js terminal gave me a practical way to explore a domain-specific model. I could inspect the financial inputs, see which tools it requested, and compare its calculations with values generated by the application.

In the examples above, Ling analyzed NVIDIA’s revenue mix, reviewed an Alphabet revenue workbook, and identified the evidence needed for a continuing-operations earnings calculation. Those are useful starting points if you are building an automated financial research tool.

I’m interested in where this kind of application can go, especially when the source material and calculations are easy to inspect. That makes it much easier to decide which parts of a workflow are ready for automation and which still need a person looking closely.

What do you think of Ling 3 Flash Fin’s API? Do you think this would be helpful in the finance industry? Let me know what you think.