This happens to me too, in a 401k account.
The problem of identifying which lot is otherwise undefined.
I'd bet this is occurring to you in a pre-tax / non-taxable returns account.
The broker takes a fee by selling some shares, and booking their "cost basis" at the market price.
They back out the number of units from the desired fee and the market price, without regards for the cost basis.
Here's an example, just to be clear:
Buy 100 FUND {100 USD}
Buy 50 FUND {102 USD}
Fee -0.04854 FUND {103 USD}
e.g. the fee above is for a 5 USD quarterly fee (0.04854 x 103 = 5.00).
But there are no shares at 103 USD.
But it doesn't matter, because gains/losses on this account is not taxable. Nobody cares.
Now, the Right Thing (TM) to do is not possible at the moment.
That would be to deduce the cost basis corresponding to the market price reported from the sum of all the basis.
This will be possible eventually, when the merging syntax will be implemented.
All lot reductions will reduce to a single lot every time the account gets modified.
In the example above, it would result in this:
Buy 100 FUND {100 USD}
Resulting inventory: 100 FUND {100 USD}
Buy 50 FUND {102 USD}
Resulting inventory: 150 FUND {100.66667 USD}
Fee -0.04854 FUND {103 USD}
Resulting inventory: 149.95145 FUND {100.66591 USD}
This will be triggered by inserting a '*' in the cost basis.
For now, what you have to do is devolve to the Ledger model, where no lot matching is carried out.
i.e. lots aren't reduced.
This will result in a lot for each posting, regardless of whether one reduces another or not.
Under this model, the values from each individual lots aren't sensible anymore, but the total number of units, and the total cost basis of all the lots in the accounts still makes sense (this is still useful).
At the moment, you can setup Beancount to do this for a particular account by giving it a default booking method of "NONE" in its corresponding Open directive.
See other email on this or the ledger list for examples. Search for "NONE".