Reporting

The Reporting page answers one question: over a chosen period, how much did we process, how fast, and at what cost?

It is a historical view. Nothing on it refreshes on its own, because nothing on it is about right now. For "is production running normally at this moment", use the Monitoring page instead.

Reporting covers production only, and only projects that have been published. A project still in design has no production history, which is not the same as having none.

Scope

The Projects control, first on the row of page controls, sets what the report covers. It sits with the other controls rather than in the title bar, because it changes what this page reports on and nothing else. It is a checklist rather than a single choice:

• Tick any combination of projects. Every figure on the page then covers those projects together, and a By project table shows where the totals come from.
• All projects ticks everything you are allowed to see. It stays current: a project published later joins the report on its own, without you revisiting the picker.
• Only, on any row, jumps straight to that one project. Use it instead of unticking everything else.
• Only the projects you have permission to report on are listed, and only published ones. You cannot untick the last project, since there would be nothing left to show.

Your selection is remembered the next time you open the page, and it applies to this page only. It never changes your current project anywhere else in the app.

The period

From and To set the range. Both days are included.

Bucket sets how the charts group time: by day, week, month or year. For anything longer than a couple of months, switch to week or month; over several years, to year. A daily series over a year is a wall of bars, not an answer.

Every number on this page depends on the range, so quote it whenever you pass a figure on. "1,204 completed" means nothing without "in July".

You can also ask the assistant to open the page already set up, for example "show me last month's reporting for Invoices and Receipts".

Reading the page

Volume and automation

Four totals for the range, then a bar per bucket split into work that bypassed review and work that was routed to a person.

Created	Transactions that arrived in the range.
Completed	Transactions that finished in the range.
Bypassed review	Completed without needing a person.
Automation rate	Bypassed review as a share of completed.

Created and completed are counted on different events, so they rarely match: something created on the last day of the range may still be in flight, and something completed on the first day may have arrived a week earlier. Automation rate deliberately divides by completed rather than created for that reason.

These are counts of transactions, not documents or pages. One transaction can hold many documents.

By project

Shown when more than one project is selected. Volume totals plus the page count for each project, so you can see which one is driving the aggregate.

Projects that did nothing in the range are hidden, so a long list stays readable. A link in the section header shows how many are hidden and brings them back. A project counts as active if anything moved or if it billed any pages, so a billable project is never hidden. The section itself can be collapsed.

The CSV button always exports every project, including the hidden ones. Hiding an idle row keeps the screen readable; leaving a project out of a page-count export you are billing against would not be.

Effort and SLA

Avg auto processing	Average time spent processing without a person.
Avg time in review	Average time an item sat with a reviewer.
SLA attainment	Share of items that finished within their service level, with the counts behind it.
Reject / redirect	Share of reviewed items that were rejected or sent back.

These are averages, not medians. Medians are not available at this level of detail. That matters when the spread is wide: a handful of items stuck for days will pull the average up while most reviews were quick, so read a high average as "something is getting stuck", not as "every review takes this long".

When several projects are selected, the averages are weighted by each project's volume, so a small project with slow reviews does not distort the overall figure.

Review taken by agents

Shown when a project's workflow has an Agent Review step that an agent worked in the range. It answers how much of the review the agents took off people.

Each time a transaction reaches an Agent Review step and an agent works it is a visit. A visit ends in one of three ways:

Settled by the agent	The agent approved, and no person decided after it in the same pass: Human Review let the transaction through, or no Human Review follows.
Reached a person	A person, or a person working through an assistant, decided at a Human Review step after it.
Ended without a person	The agent rejected or sent the transaction on, or the step failed, and nobody decided after it.

The headline is the share settled by the agent, out of all visits. The bars show the visits per bucket, split by how they ended, so the green part of each bar is what the agents settled. The table below has one row per Agent Review step, with its visits and the three groups, the failures, and the average time from a visit's start to the agent's decision. Hover over a step's Reached a person for why: after the agent rejected, after it sent the transaction on, after the step failed, or approved but still stopped by Human Review (for example because the agent made corrections). Hover over Failed for the reasons. With several projects selected, each step is named with its project. The CSV export has every step, with the breakdowns as columns.

A visit counts when its transaction finishes, as Completed does. A transaction still waiting at Human Review after the agent appears once a person has decided it.

Productivity by user

One row per person: how much they created, reviewed, approved, rejected and sent on, their reject rate, and their average review time. Agents that reviewed in the range get a row of their own: an integration key by its name, a step's built-in agent by the step's name. An agent has no review time, so it shows n/a there and its average Time to decide instead.

Use Kind to show only people, only agents, or only the people who decided through an assistant such as Claude. Those decisions count as the person's own; the arrow by the person's name shows how many were taken through each assistant. With several projects selected, a step's built-in agent is named with its project, since each project's agent is its own; an integration key is one row wherever it worked.

With All steps, people are counted as before: each transaction once, for the last person who decided it. Someone whose decision a later reviewer followed does not get a row for it here; choose that review's Step to see everyone who decided there.

Use Step to see who decided at one Human Review or Agent Review step. The rows then count every decision taken there, by whoever took it, and leave out what people created and their review time, which are not counted by step.

People with nothing in the range are hidden, with the same header link to bring them back, and the section can be collapsed. Submitting counts as activity, not just reviewing, so someone who only sends documents in still appears. The columns can be sorted, resized, moved and hidden from the menu on the last column's header, and the layout is remembered for you. As with the project table, the CSV export always includes everyone, for the Kind and Step you chose. It keeps the columns it had (the transactions a person sent on are still under redirected) and adds kind, through_clients and avg_decide_seconds. An agent's reviewed counts its decisions, a person's counts transactions, so add up reviewed for people or for agents, not across both.

When several projects are selected, each person gets one row covering all of them, not one row per project. Someone who works across three projects appears once, with their totals combined. A per-person, per-project split is not available here.

Decisions by kind and by step are recorded from the release that added them. For a range that starts earlier, a note under the table says how many transactions finished before then and are not counted in these figures.

Pages processed

The page count for the range, per bucket, with a CSV export. This is the figure licensing and billing are based on, so it is the one to quote for anything commercial. It is a page count, not a transaction or document count.

Comparing periods

There is no built-in comparison. Set one range, note the figures, then set the other. Two things to watch:

• Compare like with like. A partial period always looks worse than a full one. A month two days in has two days of volume in it.
• Keep the scope the same. Changing the selected projects between the two readings compares two different things.

When the numbers look wrong

Reporting tells you what happened, not why. Before treating a drop as a fault:

• Check intake for the same period. A stopped import connector explains a volume drop completely. The connectors section on the Monitoring page shows this, including a feed that is polling happily but has received nothing for days.
• Check whether the project was published for the whole range. A project published mid-range has no history before that point.
• Check whether the workflow changed. A new review step, a changed rule, or a different document mix all move these numbers without anything being broken.

A zero is not automatically a problem, and a rise in review time is not automatically a staffing issue.

Permissions

Capability	Permission	Built-in roles
Open Reporting and see volume, effort, SLA and per-user productivity	View reporting	Admin, Designer, Supervisor
See and export tenant-wide pages-processed totals for billing	View/export licensing page counts	Admin

Only the projects you have the reporting permission for appear in the Projects control, and only those are included in any figure on the page.