Building a Monthly Close Report Without an Analyst on Call

Close, blocked on one person's calendar

Every close, finance needs a clean view of profit by product line — completed transactions only, nothing still pending or cancelled. The number itself isn't complicated to produce. The problem is that only one or two people know exactly how to produce it, and close doesn't wait for whoever's out that week.

So close either happens on time, with whoever's available doing their best to reconstruct a query or a pivot table they don't fully remember, or it happens late, waiting on the one person who does.

Why this keeps happening

Finance teams are rarely the ones who own the database — someone in data or engineering does, and finance requests reports through them, formally or informally. Over time, "the close report" becomes a specific query or spreadsheet process that lives with whoever originally built it, not a documented, self-service step finance can run on their own. It's not a trust issue; it's that nothing about a one-off SQL query or an inherited spreadsheet formula naturally becomes something a non-technical teammate can safely rerun themselves.

The manual approach

1. Ask whoever owns the query to run it, or track down the spreadsheet process from whoever built it last.
2. Wait for a response, especially painful if that person is out or busy with something else during close week.
3. Once it arrives, check that it actually excludes pending and cancelled transactions — sometimes it doesn't, and nobody notices until the numbers look off.
4. Repeat next month, with the same dependency.

Why the manual version breaks

• Close has a hard deadline; a person's availability doesn't respect it. A single point of dependency is exactly the wrong shape for a recurring, time-sensitive process.
• The exclusion logic (completed only) isn't visible anywhere — it's inside a query or a spreadsheet formula that finance can't independently verify.
• Every request adds up to real, recurring cost on the data team's time, for a report that doesn't actually need a person to produce it each time, just the first time it's built.

A close report finance can run themselves

Here's the same profit-by-product close view, built once and saved so finance reruns it directly — no request, no wait.

Step 1 — connect the source

An Input node reads from the same PostgreSQL connection the data team already has set up — no separate access request needed once the workflow itself is shared.

Step 2 — completed transactions only

A Filter node with the condition status = completed — the exclusion rule that used to be buried in a query, now stated in plain terms on the canvas, checkable by anyone who opens the workflow.

Step 3 — profit by product

A Summarize node: measure SUM(profit), grouped by product. Close reviews profit by line, not just revenue — this is the number that actually matters for the review.

Step 4 — sort and check the query

A Sort node on profit, descending, and a Browse node showing the result and the exact query behind it:

SELECT product, SUM(profit) AS profit
FROM sales_orders
WHERE status = $1
GROUP BY product
ORDER BY profit DESC

What comes out the other side

Before: a close report that exists in one person's head or inbox, requested fresh — or chased down — every month.

After: a saved workflow finance opens and reruns directly, with the completed-only exclusion rule visible on the canvas instead of buried in a query only one person can read.

Key takeaways

• The bottleneck in most close reports isn't the calculation — it's that only one person knows how to reproduce it.
• Stating the exclusion rule (status = completed) as a visible Filter condition means finance can verify it themselves, not just trust that it was applied correctly.
• Once built, this workflow belongs to finance to rerun — not a standing request against the data team's time every month.

Next

The same pattern applies just as directly outside finance — see building a sales pipeline report from a CRM export for the equivalent built for sales ops. For the department-level view of self-service finance reporting specifically, see DataQloo for Finance.