Audit ledger
Explain why every payment happened, not only how much was paid.
Payment rails can usually tell a user how much money moved. JiesdaPay should explain why the agent spent it.
What the ledger records
Each ledger entry should connect:
- Task.
- Agent.
- Tool or hosted skill.
- Price.
- Payment rail or event.
- Reason for the call.
- Result summary.
- Approval state.
- Policy decision.
- Timestamp.
The ledger is useful only if it connects payment events back to the agent workflow that caused them.
User view
The user should see a readable task-level summary:
- Budget authorized.
- Actual spend.
- Tools called.
- Why each tool was called.
- Result summary.
- Active authorizations.
- Revocation options.
- Receipt export.
This makes agent spend understandable after the task ends.
Finance view
Finance teams need a different view:
- Organization.
- Department.
- Project or cost center.
- Vendor or service.
- Payment rail.
- Monthly spend.
- Exceptions.
- Reconciliation export.
The same ledger can power both views if events are recorded with the right dimensions from the beginning.
Why a separate ledger is needed
A payment processor feed alone is not enough. It usually does not know the agent's task, tool reason, result summary, or approval context.
JiesdaPay's ledger exists to connect money movement with agent intent and execution.