Controllers often ask for a very specific view of payables: one clean list of everything open that would be paid, so they can review cash exposure and identify exceptions.
What they usually do not want is just as important:
- No aged payables report
- No date filters quietly excluding invoices
- No separate review process that does not match what will actually be paid
They want a simple, repeatable process that is complete, minimizes errors, and eliminates redundant work.
The problem with traditional approaches
Aged payables answer the question, “How old is this liability?” Controllers reviewing payments are asking a different question: “What would we pay if we cut checks?”
When aging reports are used for payment review, teams often end up interpreting buckets that were not designed for payment decisions, reconciling totals back to a payment journal, and explaining why invoices are missing. That disconnect is where extra work and risk creep in.
The solution: Use Suggest Vendor Payments as the review engine
Instead of treating Suggest Vendor Payments as something you only run at the very end, use it as the single source of truth for controller review. This aligns what the controller reviews, what accounting approves, and what actually posts, all from the same data set.
Set ‘Last Payment Date’ far in the future to see everything open. Control payment discounts with the journal posting date.
How the process works
Run Suggest Vendor Payments using the following approach:
- Run Suggest Vendor Payments
- Set Last Payment Date far in the future so that all open invoices and credit memos are included (yes, that is what this controller wants)
- Enable Find Payment Discounts
- Use the journal posting date as the intended check date
The resulting payment journal represents a true “as if we paid everything” view.
Why payment discounts still work correctly
This is the part that often causes hesitation.
Although Last Payment Date is set far in the future, payment discounts are not evaluated using that date. Discount eligibility is evaluated using the payment journal posting date.
As long as the journal posting date reflects the intended payment date, invoice posting dates are not in the future, and you are using a single payment journal, Business Central will apply discounts correctly and take discounts only when the discount due date is on or after the posting date.
A note on design intent
This behavior is intentional. Last Payment Date was designed as a payability cutoff, not a transaction date filter. Posting Date was designed to represent when the payment actually happens.
Separating those responsibilities allows broad visibility for review and precise control over accounting and discounts. Once you understand that separation, this process becomes predictable and supportable rather than surprising.
The review step
After the journal lines are created:
- Run the Vendor Pre-Payment Report
- Send it to the controller for review
This report mirrors the payment journal exactly: what would be paid, which discounts would be taken, and the total cash impact.
If the controller redlines an invoice or credit memo, it is simply removed from the payment journal before posting. In this company, there are rarely many of these, which keeps the process efficient.
Why this matters
When payment review and payment execution use different reports, errors are almost guaranteed. This approach eliminates hidden exclusions, reduces reconciliation effort, improves controller confidence, and keeps accounting review aligned with system behavior.
Most importantly, it replaces “Why is this missing?” with “This is exactly what will be paid.”
Final takeaway
Suggest Vendor Payments is not just a payment tool. Used correctly, it is a controller review tool.
No aging reports. No rework. One list that mirrors reality.
Created as part of Sharing the Righter Way, this article blends my hands on Business Central experience with research and analysis supported by AI. I use AI as a thinking partner to explore angles, validate patterns, and accelerate the writing process, while all conclusions, explanations, and recommendations reflect my own professional judgment. The result is clearer guidance, deeper insight, and a more practical path forward for Business Central users and teams.
