"Total cost" (@@) using Beancount V3 Python API

[Zoltan]

The Beancount documentation says it supports "total cost" or "total price" using @@ symbols: https://beancount.github.io/docs/beancount_language_syntax.html

The grammar file of Beancount also has separate, distinct entries for @ and @@. 

I do currency exchanges(with no additional, explicit fees). For me, it is cleaner to declare the amount I paid and received than only the amount I paid and fiddle with the many digits of the exchange rate.

For example, this is what I would like to have:

2025-01-01 * "Exchanged to GBP"
  Assets:Bank:EUR  -117 EUR @@ 100 GBP
  Assets:Bank:GBP

And this is what I would like to avoid:

2025-01-01 * "Exchanged to GBP"
  Assets:Bank:EUR  -117 EUR @ 0.854700855 GBP
  Assets:Bank:GBP

I'm writing an importer by extending beangulp.importers.csvbase.Importer and I'm using beancount.core.data. I couldn't find any reference in the documentation how to declare total cost(@@) using the python API.

Is it possible to generate clean records of currency exchanges using an importer script where the transaction only declares the total amount paid and received?

[redst...@gmail.com]

I may be wrong, but IIRC, there’s no way to do this through the API. @@ is not very well supported. The parser has it but the Posting class doesn’t.

For what you’re wanting, shouldn’t you be wanting to avoid using @@?

​

[Daniele Nicolodi]

On 08/02/26 16:12, redst...@gmail.com wrote:
> I may be wrong, but IIRC, there’s no way to do this through the API.
> @@ is not very well supported.

This is not true. `@@` is well supported.

However, it is treated as an input only syntax that is normalize upon
parsing. Therefore, it is not expected to be represented as such in the
data model that the built-in serialization supports.

I think this could be handled extending the serialization code. However,
I see little chance for such a change to make it into beancount.

If you can live with using an external serialization library, you can
look here https://github.com/dnicolodi/beangadgets/ It contains a
version of `beancount.parser.printer` that supports writing the `@@`
syntax (and other minor improvements). I use this code for my import
scripts (I hope all the relevant local changes made it into the GitHub
repository, please holler if it does not work as expected).

Cheers,
Dan

[Zoltan]

> For what you’re wanting, shouldn’t you be wanting to avoid using @@?

What is the alternative way to solve what I'm looking for?

AFAIK this does not balance out:

2025-01-01 * "Exchanged to GBP"
  Assets:Bank:EUR  -117 EUR

  Assets:Bank:GBP   100 GBP

Thanks,

Zoltan

[Scott Gorlin]

fwiw I agree with Zoltan - with the exception of money market funds where `@ 1.00 USD` makes sense, it never makes sense to record the unit price in a transaction, as that is a derivative property of how much is actually paid.  Similar to eg Quicken where the default is 'automatically calculate price.'  Writing the unit price feels like a clear anti-pattern to me... unless I really wanted to track the rounding errors the bank is earning off me?  I have scripts that normalize and rewrite transactions and I hack the output to manually export `@@ total_price USD` everywhere.

[redst...@gmail.com]

fwiw I agree with Zoltan - with the exception of money market funds where `@ 1.00 USD` makes sense, it never makes sense to record the unit price in a transaction, as that is a derivative property of how much is actually paid.  Similar to eg Quicken where the default is 'automatically calculate price.'  Writing the unit price feels like a clear anti-pattern to me... unless I really wanted to track the rounding errors the bank is earning off me?  I have scripts that normalize and rewrite transactions and I hack the output to manually export `@@ total_price USD` everywhere.

The main reason I record the unit price in commodities held at cost is to match how my brokers store/expose it. Makes it easy to cross-check with statements when needed or for lot matching when selling. A secondary but equally important reason is to catch errors during import. It’s all too easy to miss a new type of fee or such that the importer hasn’t seen, if the total price is “absorbed in”.

With price conversions though (as opposed to commodities held at cost), as the OP says, it’s generally more important to have both sides of the transaction reflect what the banks see, the unit price is less important, and @@ is preferred.

​

[redst...@gmail.com]

For what you’re wanting, shouldn’t you be wanting to avoid using @@?

What is the alternative way to solve what I’m looking for?

My bad, I misread your statement as a desire to not have many digits in the conversion. You’re right, I’d want to do what you do in principle. As you ran into though, @@ has no API support (and this comment says even the input parser could be improved). Given that, these are some approaches I see:

Given:

2025-01-01 * "Exchanged to GBP" Assets:Bank:EUR -117 EUR Assets:Bank:GBP 100 GBP

1. hack your importer to include @@. Write out the transaction above, and have a simple text based post processor convert those transactions to use @@
2. write the transaction as you did, but write a beancount plugin to catch these and convert them to using a unit price
3. get your importer to statically do the conversion to unit price, so it looks like:

2025-01-01 * "Exchanged to GBP" Assets:Bank:EUR -117 EUR @ 0.8547 GBP Assets:Bank:GBP 100 GBP Equity:Rounding-Errors 0.0000xxx GBP ; if needed. Your importer can ensure this is a very small amount

Hope that helps.

​

[Scott Gorlin]

Apologies for going a bit tangential - but I thought this would be an interesting point to discuss somewhere

 

The main reason I record the unit price in commodities held at cost is to match how my brokers store/expose it. Makes it easy to cross-check with statements when needed or for lot matching when selling. A secondary but equally important reason is to catch errors during import. It’s all too easy to miss a new type of fee or such that the importer hasn’t seen, if the total price is “absorbed in”.

I would consider implementing this differently. The price exposed on the statement is not the price - or, perhaps not always, depending on the broker.  It is an approximation of the price, sometimes not even significant to the the point that it prints.  Vanguard, for instance, on some of my accounts (I think my 529), reports prices at 4 decimal points, but rounds it to 3 with a trailing 0, while I can get the 'more correct' price online.  I've also seen different rounding prices in CSV vs OFX exports from the same statements, and I've seen different conventions where trailing 0's are dropped only when correct vs rounding - leading to strict Decimal tolerance issues.  But even if all those were solved for, it's not actually the "price.''  When they calculate gains etc, they use whatever they use in the backend - probably to more significant digits than what is exposed.

I would suggest a more accurate method to capture that 'approximate' price and do one of two things - either raise an error on import if the 'real' price deviates from the reported price by a significant amount, or store it as metadata you can build checks on later.

I only do automatic lot specification so I'm not sure on the best approach to suggest, but I would presume your concerns are also easier to address by specifying date or label of a lot rather than a price, and let the more accurate price calculations run through.

The only downside I have encountered with 'accurate pricing' is that Fava displays all the significant digits, and that's annoying - but that would be better solved by a view setting in Fava...

​

[redst...@gmail.com]

I would consider implementing this differently. The price exposed on the statement is not the price - or, perhaps not always, depending on the broker.  It is an approximation of the price, sometimes not even significant to the the point that it prints.  Vanguard, for instance, on some of my accounts (I think my 529), reports prices at 4 decimal points, but rounds it to 3 with a trailing 0, while I can get the 'more correct' price online.  I've also seen different rounding prices in CSV vs OFX exports from the same statements, and I've seen different conventions where trailing 0's are dropped only when correct vs rounding - leading to strict Decimal tolerance issues.  But even if all those were solved for, it's not actually the "price.''  When they calculate gains etc, they use whatever they use in the backend - probably to more significant digits than what is exposed.

Most brokers store either 4 (common) or 6 (becoming common?) decimal points -- in the US at least -- and expose anywhere between 2 and the full number of decimals varyingly on the web, in their pdf statements, on ofx, and on csv. So while it’s true in principle that we users may or may not be able to import the full precision as stored, in practice I’ve found using the price as exposed by the brokerage works very well because a) they are consistent and tend to match on both ends, and b) the rounding errors that come from the store/expose delta is too low to matter. Of course, YMMV. That’s for prices. Quantities are a different story.

​

I only do automatic lot specification so I'm not sure on the best approach to suggest, but I would presume your concerns are also easier to address by specifying date or label of a lot rather than a price, and let the more accurate price calculations run through.

It doesn’t work when one has multiple transactions on the same day, and one doesn’t want to use labels (automation complexity, portability).

BTW, given the 4/6 storage, price calculations using @@ typically end up with many more decimal points, and are arguably less accurate in that they don’t match how your brokerage stores it. This might matter more from a purity standpoint though, and not in practice.

​

[Martin Blais]

There's no way to do this.

See here for background:

https://docs.google.com/document/d/1qPdNXaz5zuDQ8M9uoZFyyFis7hA0G55BEfhWhrVBsfc/edit?tab=t.0#heading=h.axs6y16wohk9

TL;DR: the AST and finalized data structures should eventually be split and the AST ones are the ones you would create to do this.

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/beancount/04770ab4-f822-4be3-addd-28bd6d4e1ec4n%40googlegroups.com.

[Zoli B.]

Thank you everyone for your help and insights.

You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/D6xpn0guLzs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/beancount/CAK21%2BhOpc0asmhrpNWLqxqnYcFWeRu3ckd61PUXX_U0-3gNX1w%40mail.gmail.com.

[Justus Pendleton]

On Tuesday, February 10, 2026 at 3:29:35 AM UTC+10:30 scott...@gmail.com wrote:

I only do automatic lot specification so I'm not sure on the best approach to suggest, but I would presume your concerns are also easier to address by specifying date or label of a lot rather than a price, and let the more accurate price calculations run through.

Neither of these really seem like plausible alternatives. When I submit a buy execution to my broker it gets filled like this:

2020-03-12 * "SMLF" #20200228-tlh-rzv
  Assets:US:Interactive-Brokers        1000 SMLF {31.4550 USD, 2020-03-12} @ 31.455 USD
  Assets:US:Interactive-Brokers         400 SMLF {30.5350 USD, 2020-03-12} @ 30.535 USD
  Assets:US:Interactive-Brokers         400 SMLF {30.5930 USD, 2020-03-12} @ 30.593 USD
  Assets:US:Interactive-Brokers        1600 SMLF {30.5900 USD, 2020-03-12} @ 30.59 USD
  Assets:US:Interactive-Brokers         600 SMLF {30.5950 USD, 2020-03-12} @ 30.595 USD
  Assets:US:Interactive-Brokers        1600 SMLF {30.6200 USD, 2020-03-12} @ 30.62 USD
  Assets:US:Interactive-Brokers         400 SMLF {30.6250 USD, 2020-03-12} @ 30.625 USD
  Assets:US:Interactive-Brokers         100 SMLF {30.4800 USD, 2020-03-12} @ 30.48 USD
  Assets:US:Interactive-Brokers         100 SMLF {30.4700 USD, 2020-03-12} @ 30.47 USD
  Assets:US:Interactive-Brokers         200 SMLF {30.3250 USD, 2020-03-12} @ 30.325 USD
  Assets:US:Interactive-Brokers         100 SMLF {30.4650 USD, 2020-03-12} @ 30.465 USD
  Assets:US:Interactive-Brokers         400 SMLF {30.4650 USD, 2020-03-12} @ 30.465 USD
  Assets:US:Interactive-Brokers         200 SMLF {30.3250 USD, 2020-03-12} @ 30.325 USD
  Assets:US:Interactive-Brokers         700 SMLF {30.4750 USD, 2020-03-12} @ 30.475 USD
  Assets:US:Interactive-Brokers         100 SMLF {30.5350 USD, 2020-03-12} @ 30.535 USD
  Assets:US:Interactive-Brokers         300 SMLF {30.5550 USD, 2020-03-12} @ 30.555 USD
  Assets:US:Interactive-Brokers         200 SMLF {30.3250 USD, 2020-03-12} @ 30.325 USD
  Assets:US:Interactive-Brokers         200 SMLF {30.5515 USD, 2020-03-12} @ 30.5515 USD

Those are all on the same date, so using a date doesn't help discriminate lots. I'm not sure what arbitrary label you could pick that is going to be meaningful or useful when I go to sell lots and need to correlate things with my broker -- they show the per-unit price of the shares in the lot. I suppose you could give a text-string label of "31.4550 USD" but...that just feels like I'm doing something wrong if I'm resorting to that.

FWIW, I've never had my broker display different per-unit pricing in different reports. It is conceivable Vanguard does but (at least until their big push for better IT in the early 2000s) they historically had the worst IT infrastructure among major brokers by a fair margin so I'd expect it to be limited to them.

[Raghav Krishnapriyan]

On Thursday, February 12, 2026 at 10:48:55 PM UTC+1 just...@gmail.com wrote:

When I submit a buy execution to my broker it gets filled like this:

2020-03-12 * "SMLF" #20200228-tlh-rzv
  Assets:US:Interactive-Brokers        1000 SMLF {31.4550 USD, 2020-03-12} @ 31.455 USD
  Assets:US:Interactive-Brokers         400 SMLF {30.5350 USD, 2020-03-12} @ 30.535 USD
  Assets:US:Interactive-Brokers         400 SMLF {30.5930 USD, 2020-03-12} @ 30.593 USD
  Assets:US:Interactive-Brokers        1600 SMLF {30.5900 USD, 2020-03-12} @ 30.59 USD
  Assets:US:Interactive-Brokers         600 SMLF {30.5950 USD, 2020-03-12} @ 30.595 USD
  Assets:US:Interactive-Brokers        1600 SMLF {30.6200 USD, 2020-03-12} @ 30.62 USD
  Assets:US:Interactive-Brokers         400 SMLF {30.6250 USD, 2020-03-12} @ 30.625 USD
  Assets:US:Interactive-Brokers         100 SMLF {30.4800 USD, 2020-03-12} @ 30.48 USD
  Assets:US:Interactive-Brokers         100 SMLF {30.4700 USD, 2020-03-12} @ 30.47 USD
  Assets:US:Interactive-Brokers         200 SMLF {30.3250 USD, 2020-03-12} @ 30.325 USD
  Assets:US:Interactive-Brokers         100 SMLF {30.4650 USD, 2020-03-12} @ 30.465 USD
  Assets:US:Interactive-Brokers         400 SMLF {30.4650 USD, 2020-03-12} @ 30.465 USD
  Assets:US:Interactive-Brokers         200 SMLF {30.3250 USD, 2020-03-12} @ 30.325 USD
  Assets:US:Interactive-Brokers         700 SMLF {30.4750 USD, 2020-03-12} @ 30.475 USD
  Assets:US:Interactive-Brokers         100 SMLF {30.5350 USD, 2020-03-12} @ 30.535 USD
  Assets:US:Interactive-Brokers         300 SMLF {30.5550 USD, 2020-03-12} @ 30.555 USD
  Assets:US:Interactive-Brokers         200 SMLF {30.3250 USD, 2020-03-12} @ 30.325 USD
  Assets:US:Interactive-Brokers         200 SMLF {30.5515 USD, 2020-03-12} @ 30.5515 USD

Those are all on the same date, so using a date doesn't help discriminate lots. I'm not sure what arbitrary label you could pick that is going to be meaningful or useful when I go to sell lots and need to correlate things with my broker -- they show the per-unit price of the shares in the lot. I suppose you could give a text-string label of "31.4550 USD" but...that just feels like I'm doing something wrong if I'm resorting to that.

Can’t you specify the lot you want to reduce by specifying its cost basis? For example:

2020-05-15 * "Sell some shares" Assets:US:InteractiveBrokers -100 SMLF {30.4800 USD}

[fin]

Raghav Krishnapriyan wrote:
> ------=_Part_168696_257337453.1770998572647
> Content-Type: multipart/alternative;
> boundary="----=_Part_168697_1720604666.1770998572647"
>
> ------=_Part_168697_1720604666.1770998572647
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable

Hi,

To keep lots distinct for me I use a lable that includes the
symbol, date and time, if you are doing a lot of transactions
you could probably include parts of a second. Or another
approach would be to use the broker's transaction number or id
which should be unique.


Fin


> On Thursday, February 12, 2026 at 10:48:55=E2=80=AFPM UTC+1 just...@gmail.c=

> om wrote:
>
> When I submit a buy execution to my broker it gets filled like this:
>
> 2020-03-12 * "SMLF" #20200228-tlh-rzv

> Assets:US:Interactive-Brokers 1000 SMLF {31.4550 USD, 2020-03-12}=
>=20
> @ 31.455 USD
> Assets:US:Interactive-Brokers 400 SMLF {30.5350 USD, 2020-03-12}=
>=20
> @ 30.535 USD
> Assets:US:Interactive-Brokers 400 SMLF {30.5930 USD, 2020-03-12}=
>=20
> @ 30.593 USD
> Assets:US:Interactive-Brokers 1600 SMLF {30.5900 USD, 2020-03-12}=
>=20
> @ 30.59 USD
> Assets:US:Interactive-Brokers 600 SMLF {30.5950 USD, 2020-03-12}=
>=20
> @ 30.595 USD
> Assets:US:Interactive-Brokers 1600 SMLF {30.6200 USD, 2020-03-12}=
>=20
> @ 30.62 USD
> Assets:US:Interactive-Brokers 400 SMLF {30.6250 USD, 2020-03-12}=
>=20
> @ 30.625 USD
> Assets:US:Interactive-Brokers 100 SMLF {30.4800 USD, 2020-03-12}=
>=20
> @ 30.48 USD
> Assets:US:Interactive-Brokers 100 SMLF {30.4700 USD, 2020-03-12}=
>=20
> @ 30.47 USD
> Assets:US:Interactive-Brokers 200 SMLF {30.3250 USD, 2020-03-12}=
>=20
> @ 30.325 USD
> Assets:US:Interactive-Brokers 100 SMLF {30.4650 USD, 2020-03-12}=
>=20
> @ 30.465 USD
> Assets:US:Interactive-Brokers 400 SMLF {30.4650 USD, 2020-03-12}=
>=20
> @ 30.465 USD
> Assets:US:Interactive-Brokers 200 SMLF {30.3250 USD, 2020-03-12}=
>=20
> @ 30.325 USD
> Assets:US:Interactive-Brokers 700 SMLF {30.4750 USD, 2020-03-12}=
>=20
> @ 30.475 USD
> Assets:US:Interactive-Brokers 100 SMLF {30.5350 USD, 2020-03-12}=
>=20
> @ 30.535 USD
> Assets:US:Interactive-Brokers 300 SMLF {30.5550 USD, 2020-03-12}=
>=20
> @ 30.555 USD
> Assets:US:Interactive-Brokers 200 SMLF {30.3250 USD, 2020-03-12}=
>=20
> @ 30.325 USD
> Assets:US:Interactive-Brokers 200 SMLF {30.5515 USD, 2020-03-12}=
>=20
> @ 30.5515 USD
>
> Those are all on the same date, so using a date doesn't help discriminate=
>=20
> lots. I'm not sure what arbitrary label you could pick that is going to be=
>=20
> meaningful or useful when I go to sell lots and need to correlate things=20
> with my broker -- they show the per-unit price of the shares in the lot. I=
>=20
> suppose you could give a text-string label of "31.4550 USD" but...that just=
>=20

> feels like I'm doing something wrong if I'm resorting to that.
>
>

> Can=E2=80=99t you specify the lot you want to reduce by specifying its cost=
> basis?=20
> For example:
>
> 2020-05-15 * "Sell some shares" Assets:US:InteractiveBrokers -100 SMLF=20
> {30.4800 USD}
>
> --=20
> You received this message because you are subscribed to the Google Groups "=
> Beancount" group.
> To unsubscribe from this group and stop receiving emails from it, send an e=
> mail to beancount+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/beancount/e=
> e024883-98d7-451e-966d-c68f30e97e7fn%40googlegroups.com.
>
> ------=_Part_168697_1720604666.1770998572647
> Content-Type: text/html; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
><br /><div><div dir=3D"auto">On Thursday, February 12, 2026 at 10:48:55=E2=
>=80=AFPM UTC+1 just...@gmail.com wrote:<br /></div><blockquote style=3D"mar=
> gin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; b=
> order-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div><div dir=3D"=
> auto"><span>When I submit a buy execution to my broker it gets filled like =
> this:</span><br /></div></div><div><div><br /></div><div>2020-03-12 * "SMLF=
> " #20200228-tlh-rzv<br />=C2=A0 Assets:US:Interactive-Brokers =C2=A0 =C2=A0=
> =C2=A0 =C2=A01000 SMLF {31.4550 USD, 2020-03-12} @ 31.455 USD<br />=C2=A0 =
> Assets:US:Interactive-Brokers =C2=A0 =C2=A0 =C2=A0 =C2=A0 400 SMLF {30.5350=
> USD, 2020-03-12} @ 30.535 USD<br />=C2=A0 Assets:US:Interactive-Brokers =
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 400 SMLF {30.5930 USD, 2020-03-12} @ 30.593 USD=
><br />=C2=A0 Assets:US:Interactive-Brokers =C2=A0 =C2=A0 =C2=A0 =C2=A01600 =
> SMLF {30.5900 USD, 2020-03-12} @ 30.59 USD<br />=C2=A0 Assets:US:Interactiv=
> e-Brokers =C2=A0 =C2=A0 =C2=A0 =C2=A0 600 SMLF {30.5950 USD, 2020-03-12} @ =
> 30.595 USD<br />=C2=A0 Assets:US:Interactive-Brokers =C2=A0 =C2=A0 =C2=A0 =
>=C2=A01600 SMLF {30.6200 USD, 2020-03-12} @ 30.62 USD<br />=C2=A0 Assets:US=
>:Interactive-Brokers =C2=A0 =C2=A0 =C2=A0 =C2=A0 400 SMLF {30.6250 USD, 202=
> 0-03-12} @ 30.625 USD<br />=C2=A0 Assets:US:Interactive-Brokers =C2=A0 =C2=
>=A0 =C2=A0 =C2=A0 100 SMLF {30.4800 USD, 2020-03-12} @ 30.48 USD<br />=C2=
>=A0 Assets:US:Interactive-Brokers =C2=A0 =C2=A0 =C2=A0 =C2=A0 100 SMLF {30.=
> 4700 USD, 2020-03-12} @ 30.47 USD<br />=C2=A0 Assets:US:Interactive-Brokers=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 200 SMLF {30.3250 USD, 2020-03-12} @ 30.325 US=
> D<br />=C2=A0 Assets:US:Interactive-Brokers =C2=A0 =C2=A0 =C2=A0 =C2=A0 100=
> SMLF {30.4650 USD, 2020-03-12} @ 30.465 USD<br />=C2=A0 Assets:US:Interact=
> ive-Brokers =C2=A0 =C2=A0 =C2=A0 =C2=A0 400 SMLF {30.4650 USD, 2020-03-12} =
> @ 30.465 USD<br />=C2=A0 Assets:US:Interactive-Brokers =C2=A0 =C2=A0 =C2=A0=
> =C2=A0 200 SMLF {30.3250 USD, 2020-03-12} @ 30.325 USD<br />=C2=A0 Assets:=
> US:Interactive-Brokers =C2=A0 =C2=A0 =C2=A0 =C2=A0 700 SMLF {30.4750 USD, 2=
> 020-03-12} @ 30.475 USD<br />=C2=A0 Assets:US:Interactive-Brokers =C2=A0 =
>=C2=A0 =C2=A0 =C2=A0 100 SMLF {30.5350 USD, 2020-03-12} @ 30.535 USD<br />=
>=C2=A0 Assets:US:Interactive-Brokers =C2=A0 =C2=A0 =C2=A0 =C2=A0 300 SMLF {=
> 30.5550 USD, 2020-03-12} @ 30.555 USD<br />=C2=A0 Assets:US:Interactive-Bro=
> kers =C2=A0 =C2=A0 =C2=A0 =C2=A0 200 SMLF {30.3250 USD, 2020-03-12} @ 30.32=
> 5 USD<br />=C2=A0 Assets:US:Interactive-Brokers =C2=A0 =C2=A0 =C2=A0 =C2=A0=
> 200 SMLF {30.5515 USD, 2020-03-12} @ 30.5515 USD</div><div><br /></div><di=
> v>Those are all on the same date, so using a date doesn't help discriminate=
> lots. I'm not sure what arbitrary label you could pick that is going to be=
> meaningful or useful when I go to sell lots and need to correlate things w=
> ith my broker -- they show the per-unit price of the shares in the lot. I s=
> uppose you could give a text-string label of "31.4550 USD" but...that just =
> feels like I'm doing something wrong if I'm resorting to that.</div></div><=
> /blockquote><div><br /></div><div>Can=E2=80=99t you specify the lot you wan=
> t to reduce by specifying its cost basis? For example:</div><div><br /></di=
> v><div><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-=
> family: SFMono-Regular, Menlo, Monaco, Consolas, &quot;Liberation Mono&quot=
> ;, &quot;Courier New&quot;, Courier, monospace; font-size: 12px; white-spac=
> e: pre; background-color: rgb(248, 248, 248);">2020-05-15 * "Sell some shar=
> es"
> Assets:US:InteractiveBrokers -100 SMLF {30.4800 </span><span st=
> yle=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: SFMono-=
> Regular, Menlo, Monaco, Consolas, &quot;Liberation Mono&quot;, &quot;Courie=
> r New&quot;, Courier, monospace; font-size: 12px; white-space: pre; backgro=
> und-color: rgb(248, 248, 248);">USD}</span></div></div>
>
><p></p>
>
> -- <br />
> You received this message because you are subscribed to the Google Groups &=
> quot;Beancount&quot; group.<br />
> To unsubscribe from this group and stop receiving emails from it, send an e=
> mail to <a href=3D"mailto:beancount+...@googlegroups.com">beancount=
> +unsub...@googlegroups.com</a>.<br />
> To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
> beancount/ee024883-98d7-451e-966d-c68f30e97e7fn%40googlegroups.com?utm_medi=
> um=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/beancount=
> /ee024883-98d7-451e-966d-c68f30e97e7fn%40googlegroups.com</a>.<br />
>
> ------=_Part_168697_1720604666.1770998572647--
>
> ------=_Part_168696_257337453.1770998572647--
>

[redst...@gmail.com]

On Thursday, February 12, 2026 at 1:48:55 PM UTC-8 just...@gmail.com wrote:

On Tuesday, February 10, 2026 at 3:29:35 AM UTC+10:30 scott...@gmail.com wrote:

I only do automatic lot specification so I'm not sure on the best approach to suggest, but I would presume your concerns are also easier to address by specifying date or label of a lot rather than a price, and let the more accurate price calculations run through.

Neither of these really seem like plausible alternatives. When I submit a buy execution to my broker it gets filled like this:

2020-03-12 * "SMLF" #20200228-tlh-rzv
  Assets:US:Interactive-Brokers        1000 SMLF {31.4550 USD, 2020-03-12} @ 31.455 USD
  Assets:US:Interactive-Brokers         400 SMLF {30.5350 USD, 2020-03-12} @ 30.535 USD

Ah yes, I’d completely forgotten about this, which my transactions are full of as well. Yet another reason @@ doesn’t work.

​

On a different note, how do you get 4 decimal points with Interactive Brokers? Looking at my journal, I seem to get two through their flexquery downloads.

 

FWIW, I've never had my broker display different per-unit pricing in different reports. It is conceivable Vanguard does but (at least until their big push for better IT in the early 2000s) they historically had the worst IT infrastructure among major brokers by a fair margin so I'd expect it to be limited to them.

I wish I could say this were true. Take Fidelity whose IT infra hasn’t had the complaints that Vanguard has had. Until recently, they provided ofx, csv, and web display (ofx is gone now). Ofx had 5 digits, while csv/web has always had two.

​

[Justus Pendleton]

On Monday, February 16, 2026 at 2:01:43 AM UTC+10:30 redst...@gmail.com wrote:

​

On a different note, how do you get 4 decimal points with Interactive Brokers? Looking at my journal, I seem to get two through their flexquery downloads.

I don't have very many transactions, usually just one or two a year (you'll notice for my example I had to go all the way back to the Covid crash of 2020) so I enter things manually, either from the daily trade report PDF they send you at the end of the day if you trade or by looking up a month-to-date activity statement PDF.