Hello,

Each transfer is an individual payee, and this payee can be taken using the function get_payees. The field on the payee is called transfer_acct for indicating which account it represents. You can get them with:

account = get_account(session, "My Account")
transfer_payee_id = accout.payee.id

Or you can get a list of them:

transfer_payees = [payee for payee in get_payees(actual.session) if payee.account]

Problem is, my actions currently do not support this transfers, because a transfer is not just setting the payee, but you need to create a corresponding transaction on the other account.

I believe I can implement it at some point, but not as of now, as it is a bit more complicated than it seems, as:

• The two transactions might not have the same date, and you have to correct it
• Second transaction might be missing, so you have to create it
• Second transaction might be unrelated, even though it has the same value

I'm not sure how actual handles all edge cases, and would have to check that to create an implementation. Do you want to run a "transfer rule" on your entire budget transactions?

Ok, so I went through the source code from Actual to figure out how this is handled by them. First of all, the transfers are processed under batchUpdateTransactions:

https://github.com/actualbudget/actual/blob/f09f4af667ddd57e031dcdb0d428ae935aa2afad/packages/loot-core/src/server/accounts/transactions.ts#L136-L147

It will then go through the transfer rules and update the transaction based on that:

https://github.com/actualbudget/actual/blob/f09f4af667ddd57e031dcdb0d428ae935aa2afad/packages/loot-core/src/server/accounts/transfer.ts#L81-L90

Currently, the user can assign any payee id on current actualpy, and it would not create the second transaction, causing the balances to be off. I would say that we do the following:

• Add a hook when modifying the payee field
• If a payee from an account is removed, the remote transaction will be too
• If a payee from an account is added, the remote transaction will be added too
• This would make the rule work as expected, but also prevent the user from breaking the local database.
• One more thing, if the transfer account is offbudget, the category is cleared

This is not a simple bug fix but I'll tackle this at some point.

Thanks for looking over this!

I found another reference in case it's useful for you. This SQL command doesn't create rules, but it works well to identify and apply transfers to historical transactions retroactively.

Even though currently on actualpy I cannot set a Transfer Payee on a Rule, there's workaround by going to the UI and selecting payee accounts manually at the Rules page.

I actually played around with it a bit, and push #110 together, do you mind giving it a try?

As far as I tried it could not corrupt one of my demo budgets, but you never know, have a backup. The worst that can happen was having unbalanced transactions.

It still cannot resolve the payee fully, as I does not look for a probable transaction on the other side. I'd have to implement this next.