An integration returns incomplete data
A connected source such as a bank feed or an external system returns less than the product expects: limited history, missing fields, ambiguous matches.
The screens were designed for complete data.
Table of Contents
Summarize with:
Key facts
- History windows and field sets differ between providers.
- Real transactions split and combine, so one-to-one matching fails.
- Showing coverage tells users which period the data spans.
- Show the evidence for suggested matches. Use a confidence score only if it is validated for that matching task, with its meaning explained.
- Automatic matching saves work and sometimes matches wrongly with nobody noticing.
Why it happens
Providers limit what they return. History windows and field sets differ between providers.
One-to-one matching. Real transactions split and combine.
Design consideration
Presented as complete
Integrated data is shown as complete, so users cannot tell a gap from an error.
How it shows up
- Reconciliation shows differences nobody can explain
- Matches are ambiguous
- Balances are partial
- Users re-enter data by hand
- Support tickets ask why a figure differs from the source system
Options and trade-offs
What helps:
- Show coverage: which period the data spans
- Suggested matches with confidence, confirmed by a person
- A queue for unmatched items
- Support for one-to-many and partial matches
The tension: automatic matching saves work, and sometimes it matches wrongly without anyone noticing. Confirming every match by hand is safe and brings back the work the feature was meant to remove.
Common mistakes
- Designing screens for complete data
- Supporting only one-to-one matches
- Hiding the period the data covers
- Leaving unmatched items without a queue