The tax outcome isn't a default.It's a decision.

Most treasury tools pick a lot-accounting method once and apply it forever. Every disposal, every transfer, every reporting period inherits a default the vendor chose, and the finance team never sees the alternative outcome sitting right next to it.

That default is itself a strategic decision. It is just usually made by the software, not by the treasury team that has to defend the result.

Bedrock treats lot selection as a policy you control. The same transaction can produce a materially different, fully documented outcome depending on the rules your team sets, and the record preserves why each outcome is what it is.

When assets move between your own wallets, Bedrock does not just mark the two halves "matched." Every inter-wallet transfer carries a visible confidence score tied to the specific evidence behind it: a shared transaction hash, a matching wallet address, or aligned amount and timing.

Treasury teams can see why the system believes two half-transactions are the same movement, and lots keep their original acquisition date and cost basis across the transfer, with the §1223(2) holding-period treatment called out on the record. A same-taxpayer transfer never silently resets the tax history behind the asset.

In Bedrock, the same transaction produced a $3,550 gain under FIFO and a $1,400 loss under a documented, rule-based lot-selection policy, with no change to the underlying transaction data. That is not an anomaly. It is the point.

Scope standing orders to tagged ledgers, prioritize strategies like "harvest losses, then minimize gains," lock lots that must never be touched, or pin a specific lot to a specific disposal with a live before-and-after preview. Every selection is recorded with its reason, so the tax outcome is a deliberate, auditable strategy decision, not whatever the software happened to do.

When holdings don't reconcile, Bedrock stops and asks the team to resolve it rather than quietly fabricating a balancing entry.

The team can synthesize a placeholder deposit (clearly badged as synthetic, valued at a $0 basis so the result is maximally defensible), or enter the real missing deposit with its actual cost basis. The synthetic-versus-real distinction stays visible in the record permanently, and the open item tracks through Action Required until it is acknowledged.

Manual entries are badged as manually entered. Value overrides cascade to dependent lots with a stated reason. Feed corrections show a preview of their blast radius before they run. And a closed period is a real boundary: a later attempt to rewind data into a closed period is explicitly blocked, not silently allowed to bleed backward into reported numbers.

The audit trail behind all of this is append-only. Records can be written and read, never updated or deleted.

Bedrock's decisions layer (tags, rules, overrides, protected lots, standing orders) exists precisely because treasury teams need to defend why a number is what it is, not just what the number is.

The platform ships with disposable sandboxes and a hands-on getting-started course that walks a new team member through the entire system, from imports and lot selection to governance and reporting, in about an hour. The workflows are built to be learned, exercised, and explained, because that is what review demands.

Bedrock connects data ingestion, lot-level inventory, a governed decisions layer, and reporting in one financial record. See how each part works:

• How it works: feeds and imports, ledgers and lots, the decisions layer, and reports
• Lot Intelligence: lot selection as governed tax strategy
• Audit & Governance: attribution, shortfalls, corrections, and period close
• For Treasury Teams: one record for finance, tax, and audit
• Written Options: connected controls for covered calls and cash-secured puts