Standard practice for financial data integration is to accept as much data as possible. If a transaction is parseable, let it through. You can clean it up later. Better to have imperfect data than missing data.
This approach is backwards and causes most integration problems.
The Beginner's Acceptance
New developers building financial integrations focus on flexibility. The data format varies slightly between sources? Write code that handles both versions. Date formats are inconsistent? Parse multiple formats. Amount has unexpected characters? Strip them out and process anyway.
This permissive approach feels pragmatic. Real-world data is messy. Systems you're integrating with have bugs and inconsistencies. If you reject everything that's not perfect, you'll reject half your data.
The reasoning makes sense until you're troubleshooting why your financial reports are wrong three months later. That transaction you flexibly parsed with the weird date format? It ended up in the wrong accounting period.
The Expert's Strictness
Experienced integration engineers embrace aggressive validation. If data doesn't match expected formats exactly, reject it. If amounts fall outside normal ranges, reject it. If required fields are missing or questionable, reject it immediately.
Strict validation seems harsh until you consider the alternative. Accepting borderline data means importing problems into your financial systems. Once bad data is in your accounting software, correcting it requires manual intervention, audit trails, and explanations to auditors.
Rejection at integration time is cleaner. The source system receives an error. Someone fixes the actual problem. Clean data flows through on the next attempt. Your financial database never contains the corrupted information.
The Maintenance Perspective
Permissive validation creates technical debt that compounds over time. You write code to handle one edge case. Then another. Soon your integration logic is full of special cases and format corrections.
Each accommodation makes the system harder to maintain. New developers can't understand why the code parses dates seventeen different ways. Documentation grows complex explaining all the data quirks you're handling.
Aggressive validation keeps integration code simple. Data either meets the specification or gets rejected. No special cases. No format juggling. The complexity stays in source systems where it belongs.
The Business Impact
Finance teams prefer working with systems that reject bad data. They'd rather investigate why a transaction was rejected than discover months later that imported data was subtly wrong.
Rejected transactions create immediate visibility. Someone knows there's a problem and can fix it. Accepted-but-wrong data hides problems until they surface during reconciliation or audits.
The controversial stance: integration should be strict gatekeepers, not flexible processors. Let source systems deal with their data quality problems rather than importing those problems into your financial infrastructure.