You built the BAQ, ran it against live data, and the numbers don’t match the AR Aged Receivables Report. The totals are off. The aging buckets don’t line up. The query looks right, but something is wrong.
This is one of the most common finance BAQ problems in Epicor Kinetic. It happens to experienced users, not just people who are new to the BAQ Designer. The gap between your query and the standard report has a specific cause, and it is fixable once you understand what is actually happening under the hood.
What the AR Aged Receivables Report Is Actually Doing
The standard report is not just pulling a list of open invoices and sorting them by date. There is more logic running behind it than most users realise.
The Aging Calculation
Kinetic’s AR Aged Receivables Report calculates aging by taking each invoice’s date, applying the customer’s payment terms to arrive at a due date, and then measuring how far past that due date the invoice sits, all relative to the aging date you enter when you run the report. That means the same invoice can land in a different aging bucket depending on the customer’s terms, the invoice date, and the as-of date you are running against.
Why the BAQ Doesn’t Pick This Up Automatically
That logic runs internally inside the report. When you build a BAQ against InvcHead in the BAQ Designer, Kinetic does not apply that same logic automatically. You have to build it in yourself, deliberately, using calculated fields. A query that skips this step will return different numbers, and it will keep returning different numbers regardless of how many times you re-check the table joins.
This is the root cause of most discrepancies between a BAQ and the standard report. It is not a data problem. It is a logic gap.
Two Versions of This Query. Most People Build the Wrong One.
Before you write a single calculated field, there is one question worth answering: do you need to see what AR looks like today, or what it looked like on a specific date in the past?
Most people skip that question and start building. That is usually where the trouble starts.
Current Aging
If you need a live view of where AR stands right now, a BAQ in Kinetic can do that. You build calculated fields that compare each open invoice’s due date against today, assign it to a bucket (Current, 1–30, 31–60, 61–90, 90+), and group by customer. The BAQ Designer supports this natively. Getting the bucket logic right takes some care, but it is a well-understood problem with a workable solution.
Historical Aging
If you need to see what AR looked like on a specific past date, that is a fundamentally different build. To do it accurately, you have to work backwards: remove every payment, new invoice, credit memo, debit memo, and adjustment posted after that date, then re-age everything against the historical date you are targeting.
Epicor community members who went down this road have described it as one of the more complex BAQ projects they have tackled. Some gave up and went back to running the standard report. For most teams, point-in-time historical aging is still a job for the standard report.
Knowing which version you actually need before you start is not a small thing. It determines how much work is ahead of you.
Why Shared Community BAQs Often Don’t Match Either
There are several community-built AR aging BAQs that have been shared across the Epicor user forums and downloaded widely. They are useful references. But users who ran them against their own data found the aging bucket totals did not match the standard report.
The Common Causes
The most frequently reported causes are straightforward once you know what to look for. Customers with payment terms that include multiple payment options are handled differently. Partially paid invoices need their remaining open balance calculated accurately, not just their original invoice amount. And credit memos need to be factored in before aging is assessed, not after.
What the Query Actually Needs to Account For
A BAQ that pulls from InvcHead alone does not account for all of this. Matching what the standard report produces requires understanding how Kinetic processes payment terms, applies cash receipts, and handles partial payments, and building that logic into the query directly. A community BAQ that worked for someone else’s data setup may not work cleanly for yours.
Use them as a starting point. Test carefully before trusting the output.
What a Well-Built AR Aging BAQ in Kinetic Actually Gives You
Most teams that go through the effort of building this query properly end up with something more useful than the standard report. Not just equivalent to it.
A Live View Instead of a Static Report
A static report you run, print, and hand to someone has a shelf life measured in hours. A well-built AR aging BAQ in Kinetic lives on a dashboard and updates continuously. Your AR team can see summarised aging by customer at a glance, click into any customer to see invoice-level detail, and filter by aging bucket or date range without running a new report each time. That is a different working experience than what the standard report offers.
Automation and Reusability
Kinetic’s System Agent supports scheduled BAQ execution and automated report distribution. You can set it to run daily, push results to the right people, and remove the manual step of generating and sharing the report entirely.
As of Kinetic 2023.2, BAQ logic can also be reused as a data source inside other BAQs. That is worth knowing if this aging query is going to feed into a broader finance or collections dashboard down the line.
Done right, this is the kind of query that changes how your AR team works. Not just where they look for a number.