Events

Understand how financial events flow through the system and drive automated journal entries.

Overview

In Axiomatic, all financial activity enters the system as events. An event represents something that happened — an invoice was issued, a payment was received, payroll was processed. The posting engine automatically transforms events into double-entry journal entries based on your DSL rules.

This event-sourced approach means your ledger is always a derived view of the underlying business events, providing a complete audit trail.

How Events Work

An event is created — either manually, via API, or automatically from imported bank transactions
The posting engine processes it — matching the event type against your published DSL rules
Journal entries are generated — across all books for the entity (e.g. GAAP, Tax, Management)
The event is marked as posted — with a link to the resulting journal entries

Each event is processed idempotently — it will never be double-posted to the same book.

Event Structure

Every event contains:

Field	Description
`entityId`	The entity this event belongs to
`type`	The event type (e.g. `invoice_issued`, `payment_received`)
`timestamp`	When the event occurred
`payload`	A JSON object with the event's financial data
`source`	How the event was created (e.g. `MANUAL`, `SYSTEM`, `IMPORT`)
`idempotencyKey`	Optional key to prevent duplicate event creation

Common Event Types

Event Type	Description	Typical Posting
`invoice_issued`	Customer invoice created	DR Accounts Receivable, CR Revenue
`payment_received`	Payment from a customer	DR Cash, CR Accounts Receivable
`payroll_processed`	Payroll run completed	DR Expense, CR Cash
`vendor_bill`	Bill received from a vendor	DR Expense, CR Accounts Payable
`vendor_payment`	Payment to a vendor	DR Expense, CR Cash
`debt_payment`	Credit card or loan payment	DR Liability, CR Cash
`income_received`	Income received (non-invoice)	DR Cash, CR Income
`crypto_received`	Crypto payment received	DR Crypto Cash, CR Revenue
`capital_contribution`	Capital invested into entity	DR Cash, CR Equity
`investment_made`	Investment purchased	DR Investment Asset, CR Cash

Posting Statuses

Every event carries a posting status that tells you what happened when it was processed:

Status	Meaning
Posted	Successfully created journal entries
Pending Approval	Journal entries created but awaiting approval
Reversed	Original entries have been reversed
Failed	Processing encountered an error (e.g. missing account mapping or FX rate)
Unposted	No matching rule found, or not yet processed

You can filter events by posting status to quickly find items that need attention.

Creating Events

Via API

POST /api/events
{
  "entityId": "your-entity-id",
  "type": "invoice_issued",
  "timestamp": "2025-06-15T00:00:00Z",
  "payload": {
    "invoice_number": "INV-2025-042",
    "counterparty": "Acme Corp",
    "total_amount": "10000.00",
    "currency": "USD",
    "description": "Advisory services — June 2025"
  }
}

The event is automatically processed through the posting engine upon creation. The response includes the processing result with any journal entries created or errors encountered.

From Bank Transactions

When you import bank transactions (via Plaid or CSV), the reconciliation engine can automatically create events from matched transactions. Each imported transaction is classified by type and promoted to an event, which then flows through the posting engine.

Manually in the UI

Navigate to the Events page and create events directly. This is useful for recording activity that doesn't come from an external feed, such as journal adjustments, accruals, or one-off transactions.

Batch Processing

Process all unprocessed events for an entity at once:

POST /api/process
{
  "entityId": "your-entity-id"
}

This processes events in chronological order and returns a summary with counts of processed, skipped, and errored events. Already-posted events are safely skipped.

Reversals

Events are never deleted. If a posting was incorrect, the system creates a reversal entry — a mirror journal entry that zeros out the original. The original entry is marked as REVERSED and the reversal is linked to it for a complete audit trail.

Reclassification

If an event was posted under the wrong type, you can reclassify it:

The original journal entries are reversed
A new correction event is created (linked to the original via correlationId)
The correction event is processed with the new event type and payload
The full chain is preserved: original → reversal → correction → new entries

On this page