How to handle lots with 2 cost basis & 2 acquisition dates?

59 views
Skip to first unread message

Justus Pendleton

unread,
Jul 4, 2025, 10:02:49 PMJul 4
to Beancount
I am subject to two tax jurisdictions. Due to reasons, my assets have different dates of acquisitions and thus different costs, in the two jurisdictions. Any ideas on ways to try to handle this in beancount or with outside tools helping?

Here's a concrete example to show what I mean

2020-03-12 * "Acquire 100 SMLF"
  Assets:US:Interactive-Brokers 100 SMLF {31.455 USD}
  Assets:US:Interactive-Brokers

when I view that under US tax laws it should be 100 shares acquired on 2020-03-12 with a cost basis of 31.455 USD.

when I view that under Australian laws it should be 100 shares acquired on 2024-10-12 with a cost basis of 66.31 USD.

To further complicate things, that "2024-10-12" means "according to the Australian time zones" which means the price actually needs to be the NYSE closing price as of 2024-10-11 due to timezones, so just pulling information from the price map is not necessarily straight forward given beancount doesn't include timezone information often making it unclear what a date refers to.

I'm reasonably sure this is Just Too Hard to try to handle in beancount but thought I'd throw it out there in case anyone has any clever ideas.

Red S

unread,
Jul 6, 2025, 11:59:54 AMJul 6
to Beancount

I've often needed the same set of transactions to be booked in two different ways, but defining separate end-to-end pipelines for each approach proved nearly impossible. My long-standing solution has been to use plugins to switch between “alternate booking worlds” on demand. For example, I rely heavily on the rename-accounts plugin, and here's another use case. In practice, I'm happy with one booking world 95% of the time and only occasionally switch to the other.

With that high level idea in mind, in your case, one idea would to have both bookings of the same transaction in your source, and use metadata + plugins to turn one set on and the other off.

You could also handle the price timing issue with a second plugin — for example, one that offsets all price entries by a day when enabled.

Reply all
Reply to author
Forward
0 new messages