Create a weekly sales report from your database

A weekly sales report needs more than a total labelled “revenue.” Decide whether you are reporting orders placed, payments collected or recognised revenue, then define refunds and the reporting period. Those decisions determine the query and how the team interprets the result, and in Datarelix you state them in the question itself when you ask the database in plain English.

You need an approved connection with access to the relevant tables or reporting views.

Agree on the measure and week

The report covers paid order value for Monday August 31 through Sunday September 6, 2026. The interval starts at August 31 00:00 and ends just before September 7 00:00, in UTC. Amounts are in EUR, excluding tax. Customer segments are recorded at the time of the order.

Refunds here mean refunds recorded against those orders as of September 10. A refund issued this week for an older order belongs to a different cash-movement report. Agree on that distinction before comparing the two totals, and record it as schema context and business definitions so later questions stay consistent.

Order	Segment	Paid order value, EUR	Refunds to review date, EUR
101	Retail	120	20
102	Retail	80	0
103	Wholesale	300	50
104	Wholesale	200	0

All four orders fall inside the week. Paid order value is EUR 700; refunds are EUR 70; paid order value less these refunds is EUR 630.

Ask for the first table

For paid orders dated August 31 through September 6, 2026, in UTC, show paid order value and refunds against those orders recorded before September 11. Use EUR excluding tax and group by the customer segment recorded on the order. Show the difference as a separate column.

If the orders live in PostgreSQL, query PostgreSQL in natural language covers the access you need. The PostgreSQL calculation aggregates refunds per order before joining them. That prevents multiple refund rows from duplicating an order’s original amount:

WITH refunds_per_order AS (
  SELECT order_id, SUM(amount_eur) AS refund_eur
  FROM refunds
  WHERE refunded_at < TIMESTAMPTZ '2026-09-11 00:00:00+00'
  GROUP BY order_id
)
SELECT o.segment_at_order,
       SUM(o.paid_value_eur) AS paid_value_eur,
       SUM(COALESCE(r.refund_eur, 0)) AS refund_eur,
       SUM(o.paid_value_eur - COALESCE(r.refund_eur, 0)) AS after_refunds_eur
FROM orders o
LEFT JOIN refunds_per_order r ON r.order_id = o.order_id
WHERE o.paid_at IS NOT NULL
  AND o.ordered_at >= TIMESTAMPTZ '2026-08-31 00:00:00+00'
  AND o.ordered_at < TIMESTAMPTZ '2026-09-07 00:00:00+00'
GROUP BY o.segment_at_order;

This assumes paid_value_eur already contains the agreed tax-exclusive paid amount, a unique order ID and completed refunds in the refund table. A source with pending refunds, partial payments or mixed currencies needs additional rules. Do not sum different currencies without an agreed conversion basis.

Check the output

Segment	Paid value, EUR	Refunds, EUR	After refunds, EUR
Retail	200	20	180
Wholesale	500	50	450

The two segments reconcile to EUR 630 after refunds. If order 103 has two refund rows of EUR 30 and EUR 20, its original EUR 300 must still be counted once. Ask a SQL reviewer to check that case and the boundary dates, using verify AI-generated SQL and results.

Your business checks are different: confirm the segment definitions, whether late-entered payments belong in the report, and which reference total the sales team uses. A mismatch may come from the definition or the data as well as the query.

Separate the review responsibilities

The sales owner confirms whether this is an order-cohort report or a report of payments and refunds received during the week. The analyst checks the order key, segment-at-order field and aggregation of multiple refunds. Use the same definition in the chart title and any report used for reconciliation.

Keep examples at both week boundaries and one order with several refunds. If a payment is entered late, decide whether the historical report should include it and at what review cutoff. If the source lacks historical segment or status fields, document that limitation rather than reconstructing past values from today’s customer record.

Make the weekly review reusable

Ask for a bar chart of the after-refund value by segment. Its bars should be Retail 180 and Wholesale 450. Add the checked chart to a private Datarelix dashboard. Keep refunds visible in a separate chart if they are a decision the team needs to discuss.

The query fixes both the order week and the refund review cutoff. A rolling weekly report needs explicit relative dates; historical totals can otherwise change as new refunds arrive. Refresh is manual and reruns the stored calculation. Exported chart images remain snapshots.

Use the dashboard walkthrough to save the report, or connect your source and begin with one week you can reconcile.