Bitcoin has no accounts and stores no balances. It tracks discrete unspent outputs, and a wallet's balance is simply the sum of the ones it can spend.
An output is spent whole or not at all
Every transaction consumes existing outputs entirely and creates new ones. There is no partial spend.
Sending an amount smaller than the output being used requires creating a second output back to the sender, which is the change.
The analogy to cash is close. Paying a small amount with a large note means receiving change, and the note itself no longer exists as such.
Validation becomes a simple check
To verify a transaction, a node confirms that each input refers to an output that exists and has not already been spent, and that the signatures authorise it.
No running balance needs to be consulted, and the checks for different transactions are independent of each other.
That independence makes validation straightforward to parallelise and removes whole categories of ordering problems that account-based systems must handle explicitly.
Privacy properties differ from accounts
Wallets generate a new address for each receipt, so holdings are spread across many outputs with no single identifier tying them together.
The link appears when outputs are combined, because spending several in one transaction is evidence that one party controls them all.
This is the basis of chain analysis, and it is why coin selection strategy affects what a wallet reveals as much as address reuse does.
Fees depend on how many outputs are used
Each input adds data to a transaction, and fees are charged by size, so spending many small outputs is expensive.
A wallet holding an amount as one large output pays much less to move it than one holding the same total in many small pieces.
Small outputs can become uneconomic to spend when fees rise above their value, which is a failure mode with no equivalent in an account-based system.
Contracts attach conditions to outputs
Each output carries a script defining what must be provided to spend it, usually a signature but potentially a time constraint or multiple signatures.
Because the condition lives on the output rather than in a persistent contract, the model suits payment conditions well and general computation poorly.
That is the deliberate trade. Account-based chains gained programmability by maintaining persistent state, and accepted the validation complexity that comes with it.