Connect ChatGPT to a SQL database for finance reporting without losing metric control
The finance team asks, "Why did recurring revenue move this month?"
A database contains the answer, but a raw ChatGPT-to-SQL connection does not contain the business definition. It may not know which subscriptions count, how refunds are treated, which timezone closes the month, or whether a backfill changed yesterday's total.
For finance reporting, the hard part is not generating SQL. It is keeping the metric definition attached to the answer.
Start with one decision, not every finance table
Choose a bounded workflow such as monthly recurring revenue movement, overdue invoices, cash collection by region, or budget-versus-actual variance.
Define the expected dimensions, date range, tenant or entity scope, currency treatment, and acceptable freshness before exposing a tool. A narrow reporting question is easier to secure and easier to verify than "ask anything about finance."
Put business definitions in approved views
Do not make the model reverse-engineer revenue policy from table names. Create an approved view or semantic layer that encodes the rules the finance team already uses.
For an MRR movement view, that may include reporting month, customer, opening MRR, expansion, contraction, churn, reactivation, and closing MRR. The view should also state the timezone and currency basis.
Related: Semantic layers for AI database agents.
Use a dedicated read-only identity
The ChatGPT workflow should connect through a role that can read the approved finance views and nothing else. It does not need access to raw payment tokens, employee data, unrelated customer fields, or mutation privileges.
If an action such as marking an invoice or updating a forecast is needed later, expose it as a separate reviewed tool. Reporting and mutation should not share an invisible permission boundary.
Make period and scope explicit
Questions such as "this month" are operationally ambiguous. Resolve them into an explicit start, end, timezone, legal entity, and comparison period before execution.
A useful tool plan might say: entity DK01, period 2026-07-01 through 2026-07-31 Europe/Copenhagen, comparison 2026-06, currency DKK, source view finance_mrr_movement_v2.
The user can confirm or correct that plan before the query runs.
Return a finance result receipt
The final answer should carry the information needed to challenge it: source view, metric version, period, filters, currency, data freshness, row count, truncation state, and query identifier.
For example: "Closing MRR increased because expansion exceeded churn for DK01, based on finance_mrr_movement_v2, refreshed at 01:00 UTC, July month-to-date versus June close."
That is more useful than a confident number detached from its accounting boundary.
Related: Audit-ready MCP database workflows.
Handle follow-up questions without changing the definition
After the first answer, finance will ask why. The tool should preserve the original period, entity, currency, and metric version while drilling into region, plan, customer segment, or movement type.
Do not let each conversational turn silently rebuild scope. Treat the reporting context as state that is visible to the user and included in the audit trail.
Example workflow
- User asks why recurring revenue changed this month.
- The connector selects the approved MRR movement tool.
- The tool resolves entity, period, timezone, currency, and metric version.
- A read-only query runs against the approved finance view.
- The result contract returns totals, movement categories, freshness, and limitations.
- ChatGPT summarizes the answer and retains the receipt for follow-up questions.
- The full chain is available for review.
Where Conexor fits
Conexor lets teams expose databases and APIs to ChatGPT and other MCP clients through governed tools. For finance reporting, that means the conversation can stay fast while the data boundary remains read-only, scoped, and auditable.
See the broader workflow design: ChatGPT database query workflows.