Skip to main content
Business Processing Reporting shows how well documents are processed and provides end-to-end transaction traceability for auditing. The Warehouse captures all transactions (completed and in progress) for analysis and visualization in business intelligence tools. Data is retained for 12 months, enabling analysis and auditing over defined time periods. The following data is tracked:
  • Transaction ID.
  • Skill ID and version.
  • Processing path by steps:
    • Step types
    • Names
    • Date and time of the start and finish of the step
    • Duration (in seconds)
  • Manual Review Operator name and email.
  • Document and transaction registration parameters.
The Warehouse does not store information about document processing events in activities that are never executed according to their settings. For example, the Assemble by files setting corresponds to the default behavior of Vantage, therefore document processing in this activity will be skipped in a workflow.

​
Understanding v1 vs v2 behavior

Before migrating, it’s important to understand that v1 and v2 differ in more than the shape of the API: they define the reporting period differently, by design. Expect different totals when comparing the two versions, not just a different request/response format. v1 filters by transaction, then returns every step of those transactions. If a transaction’s steps overlap the startDate/endDate filter window at all, all of its steps come back, including ones completed weeks before startDate or after endDate. v2 filters by step. Only the individual steps whose own CompletedUtc timestamp falls within the startDate/endDate window are returned; the rest of the transaction’s steps are excluded, even if other steps of that same transaction fall inside the window.

​
Synchronous vs. asynchronous requests

v1 is a single synchronous call: you send a GET request with query parameters and receive the report data directly in the response. v2 uses an asynchronous model instead: you submit a request, poll its status, then download the results once the report is ready. This change lets v2 handle much larger data requests without timing out. v1 is deprecated, but customers can continue using it; there’s currently no scheduled removal date.

​
Reporting period scope

The v1 and v2 endpoints define the reporting period differently. This is expected behavior, not a bug, but it means totals from the two endpoints (or from v2 reports using different date ranges) are not directly comparable.
  • v1 returns all steps belonging to any transaction that was active during the requested period, including steps that occurred outside the period’s start and end dates. For example, if a transaction started before the period began or finished after it ended, v1 still returns every step of that transaction.
  • v2 returns only the steps that actually occurred within the requested period. Steps falling outside the startDate/endDate window are excluded, even if they belong to a transaction that is partially within the period.
As a result, migrating from v1 to v2 can produce lower or different totals for the same nominal date range, since v2 no longer includes steps that fall outside the window.
Because v2 filters on each step’s own CompletedUtc, every step belongs to exactly one time window, no matter how you slice the range: a set of daily reports will sum to the same total as one report covering the equivalent multi-day range. This is a meaningful improvement over v1, where a step’s inclusion depends on whether its transaction was active during the window rather than the step’s own completion time, so v1 totals aren’t guaranteed to add up the same way across different range splits. The one thing to keep in mind with v2: a transaction whose steps span a day boundary will have those steps appear in two different daily reports, one for each day, rather than all together in either one.

​
Date filtering is based on completedUtc

In the v2 endpoint, both startDate and endDate filter against each step’s own CompletedUtc timestamp, not against any transaction-level start or end time. Because each step in a transaction (for example, Input, Classification, Extraction, Manual Review, Output) has its own CompletedUtc value, the steps of a single transaction can be spread across different dates. Each step is evaluated and included or excluded independently, based solely on its own completion time. If a transaction step gets reprocessed, corrected, re-run through Manual Review, or retried for any reason, its CompletedUtc gets updated to the new completion time. In v2, this only affects results when the query’s endDate is in the future, that is, when the window is still open. Once a query’s endDate is in the past, its results are stable: reprocessing stamps a step with the current time, which by definition falls after a window that has already closed, so it can’t retroactively enter or leave that report.

​
In-progress steps can appear in results

An export can include steps that haven’t completed yet. If a transaction has a step still in progress (for example, status Processing or WaitingForManualReview) when the report is generated, that step can still appear in the results, shown with its in-progress status and no CompletedUtc value, as long as some other part of the transaction falls within the requested period. This means a single export can mix finalized steps (with a CompletedUtc inside the window) and pending steps (with no completion timestamp at all). Check the Status column for each row rather than assuming every returned step represents a completed event. A common goal is reporting on the previous day’s transactions. Use v2 for this, with startDate and endDate set to the previous day’s 00:00:00–23:59:59 UTC window. Since v2 filters on each step’s own CompletedUtc, this returns exactly the steps that completed that day, giving you clean, consistent day-over-day totals. Avoid using v1 for this purpose. Because v1 returns every step of any transaction active during the window, a transaction with steps completed weeks before or after your target day still comes back in full, pulling unrelated steps into what should be a single day’s numbers. One tradeoff to keep in mind with the v2 approach: a transaction whose steps span midnight will have its steps split across two daily reports, one for each day, rather than appearing entirely in either one. This is expected; see Reporting period scope above. As long as endDate is for a day that’s already fully in the past, the report is stable and reproducible: re-running the same query later returns the same results. If you instead query a range that includes the current, still-in-progress day, results can change between runs as more steps complete (see Date filtering is based on CompletedUtc above).

​
Migrating from v1 to v2

​
What’s New?

In the request (/api/reporting/v2/exports/transaction-steps):
  • Filters have moved from query parameters to the request body (filters JSON object).
  • startDate, specified inside the filters object, is now required.
  • New field: sendEmailNotification (true/false) - send an email to the report request user when the report is ready to download.
In the final result’s (/api/reporting/v2/exports/transaction-steps/{{requestId}}/result/{fileIndex}) downloaded CSV files, two columns have been added:
  • DocumentsCount: The number of processed documents in a transaction.
  • PagesCount: The number of processed pages in a transaction.

​
API usage differences

v1 uses a single GET request with query parameters and returns the report directly. v2 moves filters into the request body of a POST request, then splits the process into three calls: request the report, poll its status, and download the results once it’s ready. Continue reading for details on how the v2 endpoint works below.

​
Downloading a data report

Only users with the Tenant Administrator and Processing Supervisor role can download a data report from the Warehouse. For more information, see Role-based access control.
You can obtain data from the Warehouse in a CSV file using the Vantage API. To do so, send a POST request to the following resource: A request body should include the following properties within a filters object:
  • skillId. The ID of the skill the transactions of which should be downloaded. Optional.
  • transactionId. The ID of the transaction to filter by. Optional.
  • startDate. The first day of the period (sample formatting: 2022-01-07T13:03:38, time should be in UTC) for which the transactions should be downloaded. Filters against each step’s CompletedUtc timestamp. Required.
  • endDate. The last day of the period (sample formatting: 2022-09-07T13:03:38, time should be in UTC) for which the transactions should be downloaded. Filters against each step’s CompletedUtc timestamp. Optional.
  • sendEmailNotification. Send an email to the user who created the report request, informing them the report is ready for download. Optional.
Report requests are executed asynchronously, so the response returns a requestId used to check the request status. Result:
To check the status of the report, pass the requestId in the GET request: When the report has been created, the status is “Succeeded” and totalFileCount shows the number of files available to download:
To download the resulting report files, make a GET request to the following, once again passing the requestId and adding the fileIndex, the zero-based index of the file. For example, if "totalFileCount": 3, then available file indexes would be 0, 1, and 2. Here’s a sample of what the CSV response looks like:

​
Response Structure

Each row in a CSV file is an operation performed on a transaction. For example, the import of documents, recognition, or manual review. For each operation in the Warehouse, its details are stored in columns: The prepared data is stored for 2 weeks after the request is completed. Data obtained in CSV format may be further analyzed in any BI tool.

​
Retrieving a List of Reporting Requests

To retrieve the list of reporting requests made within a designated time period, make a GET request to the following endpoint, where createdFrom and createdTo are the date range and statusFilter is one of the following values: New,Queued,Processing,Succeeded,Failed, or Cancelled. This is useful in the case of misplaced request ids. The response includes an array of reporting requests.