After our BI team updated data source mappings in Birst to accommodate new AR fields, the accounts receivable aging report stopped refreshing. The ETL job completes successfully, but the report shows data from three days ago.
When I check the data model, I can see new customer fields were added, but the aging buckets (30/60/90 days) aren’t calculating. The Birst data model alignment seems off after the mapping changes. I suspect field name consistency issues between the source and the report calculations.
Error in Birst logs:
WARNING: Field 'invoice_date' not found in source
Calculation failed for aging_bucket_30
Using cached data from 2025-04-19
The report is critical for our collections team. Anyone know how to fix data source mapping issues that break calculated fields?
Here’s the complete solution addressing all three focus areas:
Birst Data Model Alignment:
The data model needs to recognize the new field structure. Navigate to Birst Admin Console > Data Model and verify that transaction_date is properly mapped to the AR aging report’s date dimension. Update the dimension mapping:
SELECT customer_id,
TO_DATE(transaction_date, 'YYYY-MM-DD') as invoice_date,
amount
FROM ar_transactions
Data Source Mapping Changes:
Update the field mapping in your data source configuration. Go to Data Sources > AR_DataSource > Field Mappings and create a mapping rule:
Field Name Consistency:
Update all calculated fields that reference the old invoice_date field. Edit the aging bucket calculations in Report Designer:
-- Old calculation (broken)
CASE WHEN DATEDIFF(day, invoice_date, CURRENT_DATE) <= 30 THEN amount END
-- New calculation (fixed)
CASE WHEN DATEDIFF(day, TO_DATE(transaction_date, 'YYYY-MM-DD'), CURRENT_DATE) <= 30 THEN amount END
Manually trigger the ETL job to reload with corrected mappings
Verify the aging report shows current data
The root cause was the mapping update changed the field name AND data type without updating dependent calculations. This is a common issue when BI teams update source mappings without coordinating with report owners. Always validate calculated field dependencies before deploying mapping changes.
Create a test report with just the transaction_date field to verify it’s loading correctly before updating production aging reports. This helps isolate whether the issue is in the ETL transformation or the report calculation layer.
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.
The field name changed during the mapping update. Check if ‘invoice_date’ was renamed to something like ‘invoiceDate’ or ‘inv_date’. Go to Birst Admin > Data Sources > Field Mappings and search for invoice-related fields. You’ll need to update the calculated field formulas to use the new field name.
Found it! The field was renamed to ‘transaction_date’ in the new mapping. But when I try to update the aging_bucket_30 calculation to use transaction_date, I get a data type mismatch error. The old invoice_date was a date field, but transaction_date appears to be coming through as a string. How do I fix the data type in the mapping?
You need to add a data type transformation in the ETL process. The data source mapping changes probably didn’t include proper type casting. In your Birst space, edit the data source and add a transformation step that converts transaction_date from string to date format. Use the TO_DATE function with the appropriate format mask. This should resolve both the field name consistency issue and the calculation problem.
I’ve seen this happen when field mappings are updated without validating the downstream impacts. The issue is that Birst caches the old schema until you explicitly refresh it. After fixing the data type transformation, you need to go to Admin Console > Space Management and run a full schema refresh. This forces Birst to recognize the new field structure and rebuilds all dependent calculations.
Also check if the ETL transformation is preserving null values correctly. When we updated our AR mappings, null invoice dates were being converted to empty strings, which broke aging calculations. Make sure your transformation handles nulls appropriately, otherwise the aging buckets will miscalculate or fail entirely. The field name consistency requires matching not just the name but also the data handling logic.