[Bug]: Reconciled should imply cleared #843

New Issue

2026-02-28T19:21:57-06:00

GiteaMirror commented

2026-02-28 19:21:57 -06:00

Originally created by @tavlima on GitHub (Jan 1, 2024).

Verified issue does not already exist?

I have searched and found no existing issue

What happened?

This is not really a bug report, but more like a design issue (IMHO). Given cleared is a number (not a boolean), I think it would make more sense for that same field to be used as reconciled, instead of a separate attribute/column. The reason being:

those states are dependent: reconciled implies cleared, while uncleared transactions should never be flagged as reconciled. I think this logic is easier to capture by using a single column rather than enforcing this logic in multiple places.
I just found an issue where I filter by uncleared transactions and get some reconciled transactions as result, meaning my DB is in an inconsistent state. Can't tell what caused this, but this is what I see.

What error did you receive?

No response

Where are you hosting Actual?

Fly.io

What browsers are you seeing the problem on?

No response

Operating System

None

Originally created by @tavlima on GitHub (Jan 1, 2024). ### Verified issue does not already exist? - [X] I have searched and found no existing issue ### What happened? This is not really a bug report, but more like a design issue (IMHO). Given `cleared` is a number (not a boolean), I think it would make more sense for that same field to be used as `reconciled`, instead of a separate attribute/column. The reason being: 1) those states are dependent: reconciled implies cleared, while uncleared transactions should never be flagged as reconciled. I think this logic is easier to capture by using a single column rather than enforcing this logic in multiple places. 2) I just found an issue where I filter by uncleared transactions and get some reconciled transactions as result, meaning my DB is in an inconsistent state. Can't tell what caused this, but this is what I see. ### What error did you receive? _No response_ ### Where are you hosting Actual? Fly.io ### What browsers are you seeing the problem on? _No response_ ### Operating System None

GiteaMirror added the transaction reconciliation bug labels 2026-02-28 19:21:57 -06:00

GiteaMirror closed this issue

2026-02-28 19:21:57 -06:00

GiteaMirror commented

2026-02-28 19:21:57 -06:00

@jsehnoutka commented on GitHub (Jan 3, 2024):

I think this depends on the use case.

I intentionally leave some transactions uncleared in case I need the entry as a placeholder, amount to be added later (I am following the accrual principle). Current behavior of Actual enables me to reconcile and still be able to filter out uncleared transactions later.

If reconciliation would change state on my uncleared transactions, I would have no means of getting back to them when cashflow happens (to clear & reconcile them when I need to).

My use case might be very specific, but the current behavior is OK from my POV.

@jsehnoutka commented on GitHub (Jan 3, 2024): I think this depends on the use case. I intentionally leave some transactions uncleared in case I need the entry as a placeholder, amount to be added later (I am following the accrual principle). Current behavior of Actual enables me to reconcile and still be able to filter out uncleared transactions later. If reconciliation would change state on my uncleared transactions, I would have no means of getting back to them when cashflow happens (to clear & reconcile them when I need to). My use case might be very specific, but the current behavior is OK from my POV.

GiteaMirror commented

2026-02-28 19:21:58 -06:00

@tavlima commented on GitHub (Jan 4, 2024):

Couldn’t you achieve the same results by either “tagging” the transactions (using some keyword in the notes) or just leaving these transactions uncleared (and thus not reconciled)? I honestly think reconciled transactions and “amount to be added later” are essentially incompatible, by the definition of reconciled. Actual actually have a bunch of warnings exactly to avoid changes to reconciled transactions.

@tavlima commented on GitHub (Jan 4, 2024): Couldn’t you achieve the same results by either “tagging” the transactions (using some keyword in the notes) or just leaving these transactions uncleared (and thus not reconciled)? I honestly think reconciled transactions and “amount to be added later” are essentially incompatible, by the definition of reconciled. Actual actually have a bunch of warnings exactly to avoid changes to reconciled transactions.

GiteaMirror commented

2026-02-28 19:21:58 -06:00

@Jackenmen commented on GitHub (Jan 4, 2024):

Can you actually clear an uncleared transaction from UI once it's reconciled? 🤔

(sorry for the previous, deleted comment, I clicked the Comment button accidentally...)

@Jackenmen commented on GitHub (Jan 4, 2024): Can you actually clear an uncleared transaction from UI once it's reconciled? 🤔 (sorry for the previous, deleted comment, I clicked the Comment button accidentally...)

GiteaMirror commented

2026-02-28 19:21:58 -06:00

@jsehnoutka commented on GitHub (Jan 4, 2024):

... just leaving these transactions uncleared (and thus not reconciled)?...

Yes, that's exactly how I do it. I never modify reconciled transactions. I modify uncleared ones, then clear them and they get reconciled on the next reconcile task I run.

I see now that I probably misread the issue as functional - that reconciliation should overwrite all past uncleared transactions to reconciled. I see now that this is not the case - you are proposing a technical change in db which would prevent inconsistency, but shouldn't change functionality at all.

Sorry for the confusion!

@jsehnoutka commented on GitHub (Jan 4, 2024): >... just leaving these transactions uncleared (and thus not reconciled)?... Yes, that's exactly how I do it. I never modify reconciled transactions. I modify uncleared ones, then clear them and they get reconciled on the next reconcile task I run. ![image](https://github.com/actualbudget/actual/assets/133903243/ff74a77b-8bb4-4462-a6fe-8386941a6b56) I see now that I probably misread the issue as _functional_ - that reconciliation should overwrite all past `uncleared` transactions to `reconciled`. I see now that this is not the case - you are proposing a _technical change in db_ which would prevent inconsistency, but shouldn't change functionality at all. Sorry for the confusion!

GiteaMirror commented

2026-02-28 19:21:58 -06:00

@MatissJanis commented on GitHub (Jan 11, 2024):

Locked transactions should always be cleared. If they are locked and not cleared - it feels like a bug. Possibly because previously we allowed imports to update locked transactions (and also un-clear them). This has been since fixed. If there is another way to "un-clear" a transaction that is locked - I'd be interested to know how so we could patch it.

But if we take a step back to talk about the bigger architectural question - yes, we should have used a single field for cleared/locked status. But we didn't :( And column update migrations in local-first CRDTs are very cumbersome and fragile.. so I wouldn't really recommend doing that.

edit: s/reconciled/cleared/

@MatissJanis commented on GitHub (Jan 11, 2024): Locked transactions should always be cleared. If they are locked and not cleared - it feels like a bug. Possibly because previously we allowed imports to update locked transactions (and also un-clear them). This has been since fixed. If there is another way to "un-clear" a transaction that is locked - I'd be interested to know how so we could patch it. But if we take a step back to talk about the bigger architectural question - yes, we should have used a single field for cleared/locked status. But we didn't :( And column update migrations in local-first CRDTs are very cumbersome and fragile.. so I wouldn't really recommend doing that. edit: s/reconciled/cleared/

GiteaMirror commented

2026-02-28 19:21:59 -06:00

@youngcw commented on GitHub (Feb 2, 2024):

@tavlima Does this need to stay open as an issue or can this be closed?

@youngcw commented on GitHub (Feb 2, 2024): @tavlima Does this need to stay open as an issue or can this be closed?