A Daily Executive Summary from Multiple Systems: How to Build a Reliable AI Report

Short answer: a reliable daily summary starts with agreed metrics and validated data, not with a model. Code performs calculations and aggregations so they can be checked and reproduced. The model explains the calculated numbers in plain language. If a source is unavailable or has not updated, readers must see that instead of getting yesterday's value presented as today's.

The key is that incomplete or unavailable data is not zero. Fix the time zone, currency, and metric definitions before the first report. After reading, you should be able to describe a summary process using five sources, define data-quality checks, separate fact from interpretation and recommendation in the template, and decide how the report behaves when something fails.

Five sources and one glossary

A typical daily summary for an operations leader or owner combines data from several systems. For this article, consider five illustrative sources:

• CRM: new leads, deals by stage, paid deals.
• Advertising: spend, impressions, clicks, and inquiries from ad channels.
• Payments: funds received during the period.
• Support: new and resolved requests, time to first response.
• Accounting: invoices issued and accounts receivable.

The main problem with these summaries is not technical. Systems define the same thing differently. A “lead” in an ad platform and a “lead” in a CRM may be different entities. “Yesterday” ends at different times for a server in UTC and a manager in Kyiv. “Paid” in a CRM may be a manager's status label, while in a payment system it means money actually arrived.

That makes the first project artifact a metric glossary. For each metric, record:

• Name and definition: what is counted, in terms a manager understands.
• Source: the system, table, or report from which the value comes.
• Formula: how it is calculated, including filters (for example, excluding test deals).
• Period: a calendar day in a specific time zone, a week starting Monday, or a month.
• Currency: what currency to display and, when sources differ, the exchange rate and conversion date.
• Statuses: which statuses count as “paid,” “closed,” or “resolved.”
• Owner: who can change the definition.

Agree on the glossary with the manager who will use the report. Without it, a model may accurately explain numbers that each reader interprets differently.

Getting source data

There are several ways to get the data, with different levels of reliability.

System APIs. The best option for a recurring process. They provide structured values with fields, identifiers, and timestamps. You can control filters and repeat a request.

File exports. Tables generated by a system on a schedule or manually. This can work if the format is stable and you verify that the file is fresh and complete.

Data warehouse. If the company already collects system data in a warehouse, build the summary from there. That keeps quality checks and metric definitions in one place.

Dashboard screenshots. A model may technically “read” a number from an image, but this is the weakest option for a daily process. Exact values may not be extracted reliably from image-based tables, so use structured tables or text files when accuracy matters. A screenshot also hides filters, the reporting period, and the data-refresh time.

Plan the collection time as well. Systems update with different delays: ad platforms may adjust the previous day's spend for several hours, payment systems may send transactions in batches, and managers may update deals in the CRM later. If you collect data at 06:00, some values for yesterday may still change. Record when each source's daily data is considered stable, and produce the report after that time or clearly label preliminary values.

A useful rule: every value in the summary should be traceable to a specific query against a specific source for a specific period. If you cannot show that trail, leave the value out.

Quality checks

Add checks between data collection and calculation. Code runs them, and each result affects what readers see.

Common checks:

• Duplicates. A lead or payment must not be counted twice. Check identifier uniqueness.
• Missing fields. Required fields (amount, date, status) are present. Count incomplete records separately instead of silently dropping them.
• Allowed values. Statuses are from an approved list, amounts are non-negative, and dates fall within the period.
• Relationships. A payment refers to a deal that exists in the CRM.
• Freshness. Check when a source last updated. If the payment system has not received data since yesterday morning, a query may succeed technically but return stale data.
• Currency and time zone. Do not add amounts in different currencies without conversion. Normalize dates to one time zone before grouping by day.

Data transformation tools such as dbt provide checks of these kinds: uniqueness, non-null values, accepted values, relationships between tables, and source freshness. If your team already uses such a tool, add the checks there instead of duplicating them in report code.

Check results do more than block or pass data. They become part of the summary's evidence: “Three CRM records had no amount and were excluded from the calculation.”

Calculating metrics

Run all calculations before passing data to a model. Give the model the calculated values, their definitions, and the check results.

Why not ask the model to calculate:

• Reproducibility. Code returns the same result for the same data. A model's answer may vary between runs.
• Verifiability. You can read and test a formula in code. It is difficult to check a calculation embedded in a model response.
• Scale. Code is more reliable for totals and averages across thousands of rows than sending all rows into a model's context.

Even when a model writes and runs analysis code, as some tools allow, a person must review it. Before relying on the result, check the generated code, outputs, and assumptions. For a daily workflow, it is simpler to write and verify calculations once than to check new ones every day.

Pass the model:

• metric values for the current and comparison periods;
• the glossary definition of each metric;
• quality and freshness check results;
• a list of unavailable sources;
• wording rules for what can be stated as fact and what is only a possible explanation.

A summary with evidence

A useful summary clearly separates three kinds of statements.

Fact. A number with a source, period, and formula: “New CRM leads on 10 Oct: 120.”

Interpretation. A possible explanation of a change, explicitly labeled as a hypothesis: “Possible reason: the ad campaign launched on 9 Oct. Needs verification.” A model should not claim causation without analysis.

Recommendation. What to check or do and who owns it: “Ask marketing whether campaign settings changed.”

The example below is for training. All numbers are fictional.

Training summary for 10 Oct (data as of 08:00 Kyiv time)

The last row should read: “Data on funds received for 10 Oct is unavailable: the payment system has not updated since 9 Oct, 06:00. The integration owner has been notified.” It should not read: “Receipts fell to zero” or “Receipts stayed at yesterday's level.” Both invent a fact.

In a full report, every row links to the source-system report so the manager can check the number in one click, and names the metric owner.

Failures and delivery

A daily process will eventually encounter a failure. Define in advance how the report should behave.

Unavailable or stale source. Produce a partial report. Show readers which source is unavailable, the date of its latest data, and which figures cannot be calculated. Do not substitute values for unavailable data.

Failed quality checks. If a check is critical, such as widespread duplicate payments, do not publish the metric and explain why. If it is non-critical, publish it with a note.

Partial-report label. Start the summary with one line: “Report is incomplete: payment data is unavailable.” A manager should not have to search for this at the end.

Redelivery. If you regenerate the report after correcting data, label the new version as updated and include its time and a list of changes. Two different reports for one date without such a label create confusion about which one to trust.

Log. Keep input data, check results, calculated values, model text, and delivery time for every report. This lets you answer “Why did the report contain this number?” a week later.

Failure owner. A specific person gets notified when a source is unavailable or a check fails and has instructions for what to do.

Conclusion

An AI-generated executive summary is reliable when the model works at the end of the chain: after metrics are agreed, structured data is collected, quality checks run, and code performs the calculations. The model writes explanations, but does not calculate or invent causes. Unavailable data is shown as unavailable.

What you can do in your process:

1. Create a metric glossary with definitions, sources, formulas, periods, time zones, currencies, statuses, and owners. Agree on it with the manager.
2. Choose how to collect data from each source: API, export, or warehouse. Do not rely on dashboard screenshots as the main source.
3. Add checks for duplicates, missing values, allowed values, relationships, freshness, currency, and time zone.
4. Move calculations into code and give the model only calculated values, definitions, and check results.
5. Approve a template that separates facts, interpretations, and recommendations and gives every number a source, period, and formula.
6. Define failure behavior: partial report labeled at the start, updated-version labels, a log, and an owner for notifications.

If you need a daily summary from several systems that you can trust, the BotLabs team can review it with you in a 15-minute consultation. We can discuss which systems provide each metric, which definitions need agreement, and how the report should behave when a source is unavailable. The next step is to choose an initial set of metrics.

Frequently asked questions