[Feature] Reconcilliation to Lock Transactions #230

@rich-howell commented on GitHub (May 17, 2023):

Very much looking forward to someone getting a chance to work on this - my current reconciliation status is not great!

Fundamentally weather we lock or don't lock your own process is flawed, your budget is now un reliable if the reconciliation is so far out it can't be managed, no amount of locking of transactions is going to fix that unless you perform a reconciliation.

@rich-howell commented on GitHub (May 17, 2023): > Very much looking forward to someone getting a chance to work on this - my current reconciliation status is not great! Fundamentally weather we lock or don't lock your own process is flawed, your budget is now un reliable if the reconciliation is so far out it can't be managed, no amount of locking of transactions is going to fix that unless you perform a reconciliation.

GiteaMirror commented

@jflattery commented on GitHub (May 17, 2023):

This likely deserves its own ticket, but along with locking reconciled transactions, there should also be a way to filter/ hide them.

@jflattery commented on GitHub (May 17, 2023): This likely deserves its own ticket, but along with locking reconciled transactions, there should also be a way to filter/ hide them.

GiteaMirror commented

@DigisHub commented on GitHub (Jul 11, 2023):

IIRC in old YNAB you can still edit locked transactions, but a warning is displayed that it will affect the reconciliation.

Additionally, on entering reconciliation state, the locked transactions should automatically get filtered out.

@DigisHub commented on GitHub (Jul 11, 2023): IIRC in old YNAB you can still edit locked transactions, but a warning is displayed that it will affect the reconciliation. Additionally, on entering reconciliation state, the locked transactions should automatically get filtered out.

GiteaMirror commented

2026-02-28 18:53:28 -06:00

@jnimmo commented on GitHub (Jul 11, 2023):

Very much looking forward to someone getting a chance to work on this - my current reconciliation status is not great!

Fundamentally weather we lock or don't lock your own process is flawed, your budget is now un reliable if the reconciliation is so far out it can't be managed, no amount of locking of transactions is going to fix that unless you perform a reconciliation.

Correct, but at least I then know that my error is in the last month rather than potentially being anywhere in the whole history of the budget :)

@jnimmo commented on GitHub (Jul 11, 2023): > > Very much looking forward to someone getting a chance to work on this - my current reconciliation status is not great! > > Fundamentally weather we lock or don't lock your own process is flawed, your budget is now un reliable if the reconciliation is so far out it can't be managed, no amount of locking of transactions is going to fix that unless you perform a reconciliation. Correct, but at least I then know that my error is in the last month rather than potentially being anywhere in the whole history of the budget :)

GiteaMirror commented

@Rick-Thomas commented on GitHub (Jul 11, 2023):

For me the reconciliation process is important so's to be able to make sure my balances are OK and up to date... The way I would like to use it is in a 3 step process, as YNAB and other apps have:

Not reconciled, when I have spent money from an Account but the Institution has not registered it... No mark in the Cleared field...
Marked, when the Institution shows the expense has hit my Account and shows in, for example, Home Banking... The ✔️ in the Cleared field...
Reconciled, when I receive a Month End Statement where all transactions for the month are listed and I crosscheck and confirm with my records... Some mark ( 🔒 as in YNAB ?) which locks the transaction to any Amount modification, as mentioned in previous posts...

Actual lets me do 1. and 2. with no problem, but 3. is missing... Having my Bank reconciled till the end of last month, any differences that come up are current... As Actual stands today this Step 3. does not happen and I could have a difference popping up today causes by accidentally having modified an amount in an old and reconciled account, and finding that difference could be VERY cumbersome!!!

Hope this Feature comes to Actual soon!!!

@Rick-Thomas commented on GitHub (Jul 11, 2023): For me the reconciliation process is important so's to be able to make sure my balances are OK and up to date... The way I would like to use it is in a 3 step process, as YNAB and other apps have: 1. **Not reconciled**, when I have spent money from an Account but the Institution has not registered it... No mark in the Cleared field... 2. **Marked**, when the Institution shows the expense has hit my Account and shows in, for example, Home Banking... The ✔️ in the Cleared field... 3. **Reconciled**, when I receive a Month End Statement where all transactions for the month are listed and I crosscheck and confirm with my records... Some mark ( 🔒 as in YNAB ?) which locks the transaction to any Amount modification, as mentioned in previous posts... Actual lets me do 1. and 2. with no problem, but 3. is missing... Having my Bank reconciled till the end of last month, any differences that come up are current... As Actual stands today this Step 3. does not happen and I could have a difference popping up today causes by accidentally having modified an amount in an old and reconciled account, and finding that difference could be VERY cumbersome!!! Hope this Feature comes to Actual soon!!!

GiteaMirror commented

2026-02-28 18:53:28 -06:00

@JavaDogWebDesign commented on GitHub (Aug 31, 2023):

I would also love to have this feature. It locks in the cleared transactions so that it can't be accidentally modified or uncleared.

@JavaDogWebDesign commented on GitHub (Aug 31, 2023): I would also love to have this feature. It locks in the cleared transactions so that it can't be accidentally modified or uncleared.

GiteaMirror commented

@zachwhelchel commented on GitHub (Sep 11, 2023):

Currently cleared is a boolean in the schema for a transaction. Best I can tell YNAB uses an enum for cleared with the options being "cleared", "uncleared", and "reconciled". Here is their API endpoint: https://api.ynab.com/v1#/Transactions/getTransactionById

Similarly when you download your data from YNAB it corroborates the above.

Any reason to not set this up the same way? I guess we could add an extra boolean for reconciled = true but there would never be a case where cleared would be needed once reconciled is true.

Not sure how heavy a migration would be. Is there a guide or good example somewhere for how to do data migrations? @MatissJanis @rich-howell

@zachwhelchel commented on GitHub (Sep 11, 2023): Currently `cleared` is a boolean in the schema for a transaction. Best I can tell YNAB uses an enum for `cleared` with the options being "cleared", "uncleared", and "reconciled". Here is their API endpoint: https://api.ynab.com/v1#/Transactions/getTransactionById Similarly when you download your data from YNAB it corroborates the above. Any reason to not set this up the same way? I guess we could add an extra boolean for `reconciled = true` but there would never be a case where `cleared` would be needed once `reconciled` is true. Not sure how heavy a migration would be. Is there a guide or good example somewhere for how to do data migrations? @MatissJanis @rich-howell

GiteaMirror commented

@zachwhelchel commented on GitHub (Sep 11, 2023):

Currently just setting notes to "reconciled" upon a successful reconciliation in order to build out the other functionality (until the schema change decision is settled). I have the icon showing, next up is adding a warning before you try to edit it.

@zachwhelchel commented on GitHub (Sep 11, 2023): Currently just setting `notes` to "reconciled" upon a successful reconciliation in order to build out the other functionality (until the schema change decision is settled). I have the icon showing, next up is adding a warning before you try to edit it. <img width="1121" alt="Screenshot 2023-09-11 at 4 51 24 PM" src="https://github.com/actualbudget/actual/assets/869446/2360b29d-1f9a-48da-a778-687933eebf58">

GiteaMirror commented

@zachwhelchel commented on GitHub (Sep 12, 2023):

Looked over YNAB's docs to make sure there weren't any other implications for locked transactions I hadn't thought of (https://support.ynab.com/en_us/reconciling-accounts-a-guide-BJFE3fHys). The only one I'm seeing that we haven't already considered is this:

Moving forward, YNAB will only import transactions dated up to three days prior to your last reconciled transaction. This is good news, as it helps to prevent duplicates from importing!

So here is our path forward:

Schema decision: switch cleared to enum or add reconciled bool
~~Import decision: limit imports to three days prior to last reconciled transaction or leave as is~~
~~Update importers to handle reconciled transactions being imported~~
Run locking function after all reconciliation paths: adjustment needed or no adjustment needed
Add edit warning on amount change only: "Saving your changes to this reconciled transaction may bring your reconciliation out of balance."
Add delete warning: "Deleting a reconciled transaction will bring the reconciliation out of balance."
Mobile (show lock, edit warning, delete warning)
Split transaction implications
The bulk edits that just toggle cleared, think through those implications.

For the two decisions... I would lean toward switching cleared to an enum and matching YNAB's three day prior rule.

@zachwhelchel commented on GitHub (Sep 12, 2023): Looked over YNAB's docs to make sure there weren't any other implications for locked transactions I hadn't thought of (https://support.ynab.com/en_us/reconciling-accounts-a-guide-BJFE3fHys). The only one I'm seeing that we haven't already considered is this: _Moving forward, YNAB will only import transactions dated up to three days prior to your last reconciled transaction. This is good news, as it helps to prevent duplicates from importing!_ So here is our path forward: - [x] Schema decision: switch `cleared` to enum or add `reconciled` bool - [ ] ~Import decision: limit imports to three days prior to last reconciled transaction or leave as is~ - [ ] ~Update importers to handle reconciled transactions being imported~ - [x] Run locking function after all reconciliation paths: adjustment needed or no adjustment needed - [x] Add edit warning on amount change only: "Saving your changes to this reconciled transaction may bring your reconciliation out of balance." - [x] Add delete warning: "Deleting a reconciled transaction will bring the reconciliation out of balance." - [x] Mobile (show lock, edit warning, delete warning) - [x] Split transaction implications - [x] The bulk edits that just toggle cleared, think through those implications. For the two decisions... I would lean toward switching cleared to an enum and matching YNAB's three day prior rule.

GiteaMirror commented

@Rick-Thomas commented on GitHub (Sep 12, 2023):

Looked over YNAB's docs to make sure there weren't any other implications for locked transactions I hadn't thought of (https://support.ynab.com/en_us/reconciling-accounts-a-guide-BJFE3fHys). The only one I'm seeing that we haven't already considered is this:

I'm not a technical guy but YES I am a big user of the three steps (Not Reconciled, Marked and Reconciled) for a couple of reasons:

Once I've reconciled with the Bank monthly statement, no modifications to the $$$ of the transaction...
I have the option of hiding those transactions (Not sure if there is a feature request for this) because they are in the past and only needed for statistical or analysis reasons... Don't want them cluttering the register unless I need it...

So for whatever it's worth, I'm all for this feature implementation, together with the Hiding Reconciled Transactions one...

@Rick-Thomas commented on GitHub (Sep 12, 2023): > Looked over YNAB's docs to make sure there weren't any other implications for locked transactions I hadn't thought of (https://support.ynab.com/en_us/reconciling-accounts-a-guide-BJFE3fHys). The only one I'm seeing that we haven't already considered is this: I'm not a technical guy but YES I am a big user of the three steps (Not Reconciled, Marked and Reconciled) for a couple of reasons: 1. Once I've reconciled with the Bank monthly statement, no modifications to the $$$ of the transaction... 2. I have the option of hiding those transactions (Not sure if there is a feature request for this) because they are in the past and only needed for statistical or analysis reasons... Don't want them cluttering the register unless I need it... So for whatever it's worth, I'm all for this feature implementation, together with the Hiding Reconciled Transactions one...

GiteaMirror commented

@zachwhelchel commented on GitHub (Sep 12, 2023):

Errors are now showing when you try to edit a reconciled transaction. There is some weird behavior in the differences between the following:

hitting "Tab" after editing the amount. (works as expected)
hitting "Return" after editing the amount. (fires the onUpdate twice if last item in list)
tapping away from the input field after editing the amount. (doesn't refresh the input now that onUpdate is interrupted with a modal)
bulk edits don't trigger onUpdate. (just another case that needs to be handled)

Working through handling all these cases.

@zachwhelchel commented on GitHub (Sep 12, 2023): Errors are now showing when you try to edit a reconciled transaction. There is some weird behavior in the differences between the following: - hitting "Tab" after editing the amount. (works as expected) - hitting "Return" after editing the amount. (fires the onUpdate twice if last item in list) - tapping away from the input field after editing the amount. (doesn't refresh the input now that onUpdate is interrupted with a modal) - bulk edits don't trigger onUpdate. (just another case that needs to be handled) Working through handling all these cases. <img width="1334" alt="Screenshot 2023-09-12 at 4 53 43 PM" src="https://github.com/actualbudget/actual/assets/869446/862b340f-cf37-4b62-a996-1f2975a51e7a">

GiteaMirror commented

2026-02-28 18:53:30 -06:00

@JavaDogWebDesign commented on GitHub (Sep 12, 2023):

This is how the reconcile feature works on Financier. When I click on Reconcile, the popup will confirm whether the transaction is correct:

If I click on no, it'll ask for the correct amount (if i click on yes, it'll just lock up all cleared transactions):

Then it'll ask if I'd like to add or remove a certain amount to bring it to the current balance:

Then it auto-creates the transaction:

Is this something that you're working towards? I use the reconcile feature and click on "no" and auto create to bring to the current balance a lot with investment accounts and cash.

@JavaDogWebDesign commented on GitHub (Sep 12, 2023): This is how the reconcile feature works on Financier. When I click on Reconcile, the popup will confirm whether the transaction is correct: <img width="290" alt="image" src="https://github.com/actualbudget/actual/assets/50428613/2d490273-48c1-4c37-a090-988e7a1b1e19"> If I click on no, it'll ask for the correct amount (if i click on yes, it'll just lock up all cleared transactions): <img width="294" alt="image" src="https://github.com/actualbudget/actual/assets/50428613/3abbd422-d37b-4b8c-9bfe-31da47bfc9f0"> Then it'll ask if I'd like to add or remove a certain amount to bring it to the current balance: <img width="1072" alt="image" src="https://github.com/actualbudget/actual/assets/50428613/d27aaa2e-11c2-4009-991c-285b4ee740e5"> Then it auto-creates the transaction: <img width="1072" alt="image" src="https://github.com/actualbudget/actual/assets/50428613/1fc9b767-c996-4584-a091-9bb49c533bc1"> Is this something that you're working towards? I use the reconcile feature and click on "no" and auto create to bring to the current balance a lot with investment accounts and cash.

GiteaMirror commented

@zachwhelchel commented on GitHub (Sep 13, 2023):

@JavaDogWebDesign that concept is already included in Actual. This issue is for making sure that the transactions appear as "locked" once you've reconciled.

@zachwhelchel commented on GitHub (Sep 13, 2023): @JavaDogWebDesign that concept is already included in Actual. This issue is for making sure that the transactions appear as "locked" once you've reconciled.

GiteaMirror commented

@JavaDogWebDesign commented on GitHub (Sep 13, 2023):

Ah, got it. Have you tried asking for a follow-up on discord? Helpful bunch of folks there may be able to answer the question.

@JavaDogWebDesign commented on GitHub (Sep 13, 2023): Ah, got it. Have you tried asking for a follow-up on discord? Helpful bunch of folks there may be able to answer the question.

GiteaMirror commented

@MatissJanis commented on GitHub (Sep 13, 2023):

Sorry for the slow response @zachwhelchel . I try to prioritize PRs over discussions on issues or discord, so it takes a bit of time to respond.

Schema decision: switch cleared to enum or add reconciled bool

I would recommend to add a new column. Historically we've had problems when renaming/altering existing columns (sync breaking for some folks). Obviously it won't be as clean as switching to an enum, but it will be more stable and secure.

Import decision: limit imports to three days prior to last reconciled transaction or leave as is

What's easier? To leave as-is or to implement this new logic? I'd go with the path of least resistance for the initial version and then see if we get some feedback from the community.

Let me know if there's anything else I can help with! Super exciting to see all the work you're doing and I can't wait to review it.

@MatissJanis commented on GitHub (Sep 13, 2023): Sorry for the slow response @zachwhelchel . I try to prioritize PRs over discussions on issues or discord, so it takes a bit of time to respond. > Schema decision: switch cleared to enum or add reconciled bool I would recommend to add a new column. Historically we've had problems when renaming/altering existing columns (sync breaking for some folks). Obviously it won't be as clean as switching to an enum, but it will be more stable and secure. > Import decision: limit imports to three days prior to last reconciled transaction or leave as is What's easier? To leave as-is or to implement this new logic? I'd go with the path of least resistance for the initial version and then see if we get some feedback from the community. Let me know if there's anything else I can help with! Super exciting to see all the work you're doing and I can't wait to review it.

GiteaMirror commented

@jflattery commented on GitHub (Sep 13, 2023):

I would recommend to add a new column. Historically we've had problems when renaming/altering existing columns (sync breaking for some folks). Obviously it won't be as clean as switching to an enum, but it will be more stable and secure.

@MatissJanis I think this could cause issues further down the line. Should a transaction that hasn't cleared yet ever be reconciled? I would adamantly argue no, that is only going to cause frustration for the user down the road when that transaction clears and its final value is off from the original amount. Having these as two separate fields means more checks and complexity need to be added.

@jflattery commented on GitHub (Sep 13, 2023): > I would recommend to add a new column. Historically we've had problems when renaming/altering existing columns (sync breaking for some folks). Obviously it won't be as clean as switching to an enum, but it will be more stable and secure. @MatissJanis I think this could cause issues further down the line. Should a transaction that hasn't cleared yet ever be reconciled? I would adamantly argue no, that is only going to cause frustration for the user down the road when that transaction clears and its final value is off from the original amount. Having these as two separate fields means more checks and complexity need to be added.

GiteaMirror commented

@Rick-Thomas commented on GitHub (Sep 14, 2023):

I would recommend to add a new column. Historically we've had problems when renaming/altering existing columns (sync breaking for some folks). Obviously it won't be as clean as switching to an enum, but it will be more stable and secure.

@MatissJanis I think this could cause issues further down the line. Should a transaction that hasn't cleared yet ever be reconciled? I would adamantly argue no, that is only going to cause frustration for the user down the road when that transaction clears and its final value is off from the original amount. Having these as two separate fields means more checks and complexity need to be added.

I agree... Not to mention valuable monitor real estate it would require...

@Rick-Thomas commented on GitHub (Sep 14, 2023): > > I would recommend to add a new column. Historically we've had problems when renaming/altering existing columns (sync breaking for some folks). Obviously it won't be as clean as switching to an enum, but it will be more stable and secure. > > @MatissJanis I think this could cause issues further down the line. Should a transaction that hasn't cleared yet ever be reconciled? I would adamantly argue no, that is only going to cause frustration for the user down the road when that transaction clears and its final value is off from the original amount. Having these as two separate fields means more checks and complexity need to be added. I agree... Not to mention valuable monitor real estate it would require...

GiteaMirror commented