Customer aging analytics report shows incorrect balances after migration

We completed our migration from a legacy AR system to CloudSuite Analytics last week, and I’m seeing significant discrepancies in our customer aging reports. The balances in the 30-60 and 60-90 day buckets don’t match what we had in our source system.

Our legacy system used a different aging logic based on due date rather than invoice date, and I suspect this is causing the mismatch. The credit control team is flagging accounts that appear overdue in CloudSuite but were current in the old system. We verified the invoice data migrated correctly, but the aging calculation seems off.

Has anyone dealt with aging logic differences post-migration? How do we reconcile these balances and ensure our reporting aligns with our legacy calculations?

Let me provide a comprehensive solution addressing all three aspects of your migration challenge.

Legacy System Aging Logic Migration: The core issue is that your legacy system calculated aging from the due date, while CloudSuite defaults to invoice date. Navigate to AR Setup > Aging Configuration and change the “Aging Basis” parameter from “Invoice Date” to “Due Date”. This aligns the calculation method with your legacy system. Additionally, verify the “Days Past Due Calculation” setting matches your previous logic (calendar days vs. business days).

Post-Migration Balance Reconciliation: Since your migration completed last week, you need a reconciliation strategy. First, create a validation report comparing legacy aging snapshots against CloudSuite recalculated aging using the corrected basis. The discrepancy should narrow significantly once you switch to due date aging. For the remaining differences, investigate:

  • Payment application timing differences (payments posted near month-end)
  • Credit memos that weren’t properly linked to invoices during migration
  • Disputed invoices that may have had special aging treatment in the legacy system

Source System Balance Alignment: To ensure ongoing accuracy, implement these validation checkpoints:

  1. Run a trial balance comparison between your legacy system’s final AR snapshot and CloudSuite’s opening balances
  2. Create a custom aging report that includes both invoice date and due date columns for the next 60-90 days
  3. Set up automated aging variance alerts (threshold >5%) to catch calculation drift early
  4. Document any intentional differences in aging methodology for audit purposes

For the credit control team’s immediate needs, I recommend creating a temporary “Migration Reconciliation” report that flags accounts showing significant aging bucket shifts. This helps them understand which customers truly need follow-up versus those affected by the calculation change.

One critical step: before changing the aging basis system-wide, test it in a sandbox environment with your actual migrated data to confirm the results match expectations. This prevents surprises when you apply the change to production.


This draft is based on general Infor CloudSuite knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

This is a common issue when migrating to CloudSuite Analytics. The default aging calculation uses invoice date, not due date. You’ll need to check your aging bucket configuration in the AR module settings. There’s usually an option to switch the aging basis from invoice date to due date or payment terms date.

Thanks for the quick response. I checked the AR module configuration and found the aging basis setting. It was indeed set to invoice date. However, when I try to change it to due date, I get a warning that this will affect historical reporting. Should I be concerned about losing historical data or affecting prior period reports that have already been generated?

The warning is just cautionary. Historical reports won’t be lost, but they’ll recalculate based on the new aging logic when you regenerate them. If you need to preserve both views, consider creating a custom aging report definition that uses due date logic while keeping the standard report unchanged. This gives your credit control team both perspectives during the transition period.

I went through this exact scenario six months ago. One thing to watch out for is how partial payments are handled. Our legacy system applied payments differently, which compounded the aging discrepancy. Make sure you validate not just the aging basis but also the payment application rules. We had to create a reconciliation report that ran both calculations side-by-side for the first quarter to build confidence with the finance team.

That’s a great point about payment application. I’ll need to review those rules as well. Did you use any specific CloudSuite Analytics features to create your reconciliation report, or was it a custom development?

We used the standard report writer with custom calculated fields. Created two aging columns - one using the native CloudSuite logic and one with a formula mimicking our legacy calculation. Worked well enough for the transition.

Worked well enough for the transition.