fix(qif): preserve transactions with repeated check references

[smitzo]

Summary

• keep QIF N check/reference values in the raw record instead of exposing them as bank-assigned FITIDs
• let QIF transactions use the existing content-based deduplication path
• add an end-to-end regression test proving two distinct NATM transactions both survive normalization
• correct the QIF deduplication entry in the format support matrix

Root cause

QIF defines N as a check or reference value, not a guaranteed-unique downloaded transaction identifier. The parser stored N in Transaction.fitid, while the deduplication layer treats every non-empty FITID as authoritative. Repeated values such as ATM or EFT could therefore cause later, unrelated transactions to be silently discarded—even within one input statement.

The QIF N value remains available in Transaction.raw for traceability.

Format evidence

• The archived Intuit QIF field specification defines N for non-investment transactions as the check or reference number.
• Current Quicken register documentation lists Check #, Reference, and FITID separately, and describes FITID as the unique identifier assigned to a downloaded transaction.
• Quicken also documents that the Check # field supports predefined and custom transaction types, so values such as ATM are not unique transaction identifiers.

Impact

Normalization no longer loses distinct QIF transactions merely because they share a check/reference value.

Compatibility

QIF JSON now reports fitid: null instead of mislabeling N as a FITID. Python callers can still read the original N value from Transaction.raw. Introducing a new public reference field is intentionally left outside this focused correctness fix.

[smitzo]

Summary

• keep QIF N check/reference values in the raw record instead of exposing them as bank-assigned FITIDs
• let QIF transactions use the existing content-based deduplication path
• add an end-to-end regression test proving two distinct NATM transactions both survive normalization
• correct the QIF deduplication entry in the format support matrix

Root cause

QIF defines N as a check or reference value, not a guaranteed-unique downloaded transaction identifier. The parser stored N in Transaction.fitid, while the deduplication layer treats every non-empty FITID as authoritative. Repeated values such as ATM or EFT could therefore cause later, unrelated transactions to be silently discarded—even within one input statement.

The QIF N value remains available in Transaction.raw for traceability.

Format evidence

• The archived Intuit QIF field specification defines N for non-investment transactions as the check or reference number.
• Current Quicken register documentation lists Check #, Reference, and FITID separately, and describes FITID as the unique identifier assigned to a downloaded transaction.
• Quicken also documents that the Check # field supports predefined and custom transaction types, so values such as ATM are not unique transaction identifiers.

Impact

Normalization no longer loses distinct QIF transactions merely because they share a check/reference value.

Compatibility

QIF JSON now reports fitid: null instead of mislabeling N as a FITID. Python callers can still read the original N value from Transaction.raw. Introducing a new public reference field is intentionally left outside this focused correctness fix.

[smitzo]

Summary

• keep QIF N check/reference values in the raw record instead of exposing them as bank-assigned FITIDs
• let QIF transactions use the existing content-based deduplication path
• add an end-to-end regression test proving two distinct NATM transactions both survive normalization
• correct the QIF deduplication entry in the format support matrix

Root cause

QIF defines N as a check or reference value, not a guaranteed-unique downloaded transaction identifier. The parser stored N in Transaction.fitid, while the deduplication layer treats every non-empty FITID as authoritative. Repeated values such as ATM or EFT could therefore cause later, unrelated transactions to be silently discarded—even within one input statement.

The QIF N value remains available in Transaction.raw for traceability.

Format evidence

• The archived Intuit QIF field specification defines N for non-investment transactions as the check or reference number.
• Current Quicken register documentation lists Check #, Reference, and FITID separately, and describes FITID as the unique identifier assigned to a downloaded transaction.
• Quicken also documents that the Check # field supports predefined and custom transaction types, so values such as ATM are not unique transaction identifiers.

Impact

Normalization no longer loses distinct QIF transactions merely because they share a check/reference value.

Compatibility

QIF JSON now reports fitid: null instead of mislabeling N as a FITID. Python callers can still read the original N value from Transaction.raw. Introducing a new public reference field is intentionally left outside this focused correctness fix.

[smitzo]

Summary

• keep QIF N check/reference values in the raw record instead of exposing them as bank-assigned FITIDs
• let QIF transactions use the existing content-based deduplication path
• add an end-to-end regression test proving two distinct NATM transactions both survive normalization
• correct the QIF deduplication entry in the format support matrix

Root cause

QIF defines N as a check or reference value, not a guaranteed-unique downloaded transaction identifier. The parser stored N in Transaction.fitid, while the deduplication layer treats every non-empty FITID as authoritative. Repeated values such as ATM or EFT could therefore cause later, unrelated transactions to be silently discarded—even within one input statement.

The QIF N value remains available in Transaction.raw for traceability.

Format evidence

• The archived Intuit QIF field specification defines N for non-investment transactions as the check or reference number.
• Current Quicken register documentation lists Check #, Reference, and FITID separately, and describes FITID as the unique identifier assigned to a downloaded transaction.
• Quicken also documents that the Check # field supports predefined and custom transaction types, so values such as ATM are not unique transaction identifiers.

Impact

Normalization no longer loses distinct QIF transactions merely because they share a check/reference value.

Compatibility

QIF JSON now reports fitid: null instead of mislabeling N as a FITID. Python callers can still read the original N value from Transaction.raw. Introducing a new public reference field is intentionally left outside this focused correctness fix.

[smitzo]

Summary

• keep QIF N check/reference values in the raw record instead of exposing them as bank-assigned FITIDs
• let QIF transactions use the existing content-based deduplication path
• add an end-to-end regression test proving two distinct NATM transactions both survive normalization
• correct the QIF deduplication entry in the format support matrix

Root cause

QIF defines N as a check or reference value, not a guaranteed-unique downloaded transaction identifier. The parser stored N in Transaction.fitid, while the deduplication layer treats every non-empty FITID as authoritative. Repeated values such as ATM or EFT could therefore cause later, unrelated transactions to be silently discarded—even within one input statement.

The QIF N value remains available in Transaction.raw for traceability.

Format evidence

• The archived Intuit QIF field specification defines N for non-investment transactions as the check or reference number.
• Current Quicken register documentation lists Check #, Reference, and FITID separately, and describes FITID as the unique identifier assigned to a downloaded transaction.
• Quicken also documents that the Check # field supports predefined and custom transaction types, so values such as ATM are not unique transaction identifiers.

Impact

Normalization no longer loses distinct QIF transactions merely because they share a check/reference value.

Compatibility

QIF JSON now reports fitid: null instead of mislabeling N as a FITID. Python callers can still read the original N value from Transaction.raw. Introducing a new public reference field is intentionally left outside this focused correctness fix.

[smitzo]

Summary

• keep QIF N check/reference values in the raw record instead of exposing them as bank-assigned FITIDs
• let QIF transactions use the existing content-based deduplication path
• add an end-to-end regression test proving two distinct NATM transactions both survive normalization
• correct the QIF deduplication entry in the format support matrix

Root cause

QIF defines N as a check or reference value, not a guaranteed-unique downloaded transaction identifier. The parser stored N in Transaction.fitid, while the deduplication layer treats every non-empty FITID as authoritative. Repeated values such as ATM or EFT could therefore cause later, unrelated transactions to be silently discarded—even within one input statement.

The QIF N value remains available in Transaction.raw for traceability.

Format evidence

• The archived Intuit QIF field specification defines N for non-investment transactions as the check or reference number.
• Current Quicken register documentation lists Check #, Reference, and FITID separately, and describes FITID as the unique identifier assigned to a downloaded transaction.
• Quicken also documents that the Check # field supports predefined and custom transaction types, so values such as ATM are not unique transaction identifiers.

Impact

Normalization no longer loses distinct QIF transactions merely because they share a check/reference value.

Compatibility

QIF JSON now reports fitid: null instead of mislabeling N as a FITID. Python callers can still read the original N value from Transaction.raw. Introducing a new public reference field is intentionally left outside this focused correctness fix.

[smitzo]

Summary

• keep QIF N check/reference values in the raw record instead of exposing them as bank-assigned FITIDs
• let QIF transactions use the existing content-based deduplication path
• add an end-to-end regression test proving two distinct NATM transactions both survive normalization
• correct the QIF deduplication entry in the format support matrix

Root cause

QIF defines N as a check or reference value, not a guaranteed-unique downloaded transaction identifier. The parser stored N in Transaction.fitid, while the deduplication layer treats every non-empty FITID as authoritative. Repeated values such as ATM or EFT could therefore cause later, unrelated transactions to be silently discarded—even within one input statement.

The QIF N value remains available in Transaction.raw for traceability.

Format evidence

• The archived Intuit QIF field specification defines N for non-investment transactions as the check or reference number.
• Current Quicken register documentation lists Check #, Reference, and FITID separately, and describes FITID as the unique identifier assigned to a downloaded transaction.
• Quicken also documents that the Check # field supports predefined and custom transaction types, so values such as ATM are not unique transaction identifiers.

Impact

Normalization no longer loses distinct QIF transactions merely because they share a check/reference value.

Compatibility

QIF JSON now reports fitid: null instead of mislabeling N as a FITID. Python callers can still read the original N value from Transaction.raw. Introducing a new public reference field is intentionally left outside this focused correctness fix.

[smitzo]

Summary

• keep QIF N check/reference values in the raw record instead of exposing them as bank-assigned FITIDs
• let QIF transactions use the existing content-based deduplication path
• add an end-to-end regression test proving two distinct NATM transactions both survive normalization
• correct the QIF deduplication entry in the format support matrix

Root cause

QIF defines N as a check or reference value, not a guaranteed-unique downloaded transaction identifier. The parser stored N in Transaction.fitid, while the deduplication layer treats every non-empty FITID as authoritative. Repeated values such as ATM or EFT could therefore cause later, unrelated transactions to be silently discarded—even within one input statement.

The QIF N value remains available in Transaction.raw for traceability.

Format evidence

• The archived Intuit QIF field specification defines N for non-investment transactions as the check or reference number.
• Current Quicken register documentation lists Check #, Reference, and FITID separately, and describes FITID as the unique identifier assigned to a downloaded transaction.
• Quicken also documents that the Check # field supports predefined and custom transaction types, so values such as ATM are not unique transaction identifiers.

Impact

Normalization no longer loses distinct QIF transactions merely because they share a check/reference value.

Compatibility

QIF JSON now reports fitid: null instead of mislabeling N as a FITID. Python callers can still read the original N value from Transaction.raw. Introducing a new public reference field is intentionally left outside this focused correctness fix.