Skip to main content

Concepts

Earmark models deal money as a chain of governed states inside your ledger, rather than a promise remembered outside it. These are the ideas that carry it.

The deal is the only source of money​

Nothing prices, accrues or claims until a deal is approved. A deal names its module (customer, vendor or inventory), its shape, who it targets on four axes using the Table / Group / All grammar you already maintain for trade agreements, its validity window, and its economics: an amount per unit, a percent of base, or a fixed amount per transaction, exactly one of the three. Approval rides native workflow, and segregation of duties is seeded as rules so that the author of a deal cannot approve it and the approver of deals cannot approve claims.

Closing, canceling or letting a deal expire ends its availability for new prices only. Money already frozen onto order lines stays a live commitment and settles normally; reversing it is a separate, deliberate, reason-coded action, never a side effect of a status change.

A priced line is a contract​

When an order line is accepted, Earmark builds its price as base plus over-basis plus deal money and stores that decomposition, per price unit, in transaction and accounting currency with the build rate recorded. In gross-up mode the deal money is added to the invoiced unit price; in off-invoice mode the price stays at base plus over-basis and the deal money is carried as an allowance. Either way the claim side is identical.

The build is a snapshot. A deal amended afterwards applies to new lines; the accepted line keeps the promise that was made. If the line itself changes after pricing, Earmark flags it stale and offers a controlled rebuild rather than silently repricing it. Eligibility is evaluated on the date goods are expected to move, in the deal's own unit: a deal whose unit cannot be converted to the line's is ineligible, never mis-scaled.

The accrual chain​

Each frozen deal component on a line is an accrual instance bound to the inventory transaction. When the trigger document posts, at shipment, at invoice or on demand, an event is queued after the native document commits, so a packing slip is never held hostage by finance configuration. The engine then posts one journal per movement in the deal's currency, with every movement carrying an explicit state and an immutable link to its parent. A returned shipment reverses its accrual; a claimed accrual cannot be claimed again. Anything a hook could not capture lands in the unaccrued-transactions safety net rather than vanishing.

Accrued amounts either revalue through the standard general ledger revaluation or lock to the build rate, per company policy, so an accrual and its reversal always net to zero.

Controls that act at the moment of accrual​

A lifetime cap, per-transaction limits and quantity thresholds are stored on the deal and evaluated when a movement posts, against a balance maintained in the same transaction. A cap is a ceiling the engine enforces, not a number a report checks later. A headroom percentage warns the deal owner as room runs out, and the deal control workspace shows every deal's position, breaches, pending accruals and execution exceptions without anyone running a query.

The claim is a document, and it ends at the credit​

Claimable accruals are gathered into a claim document, worked from a queue, and approved through native workflow with its own segregation rules. Approval posts a credit to the customer's invoice account, one voucher per claim line, tied back to the accrual chain. Everything after that is standard accounts receivable: settlement on account, a refund proposal, statements. The customer claim statement is generated from the ledger's own records and shows approved money available for settlement in the customer's currency.

One engine, two sides​

The vendor side is the same engine with the counterparty and direction flipped. Supplier rebates accrue at goods receipt and are claimed from the supplier as an accounts-payable proposal. A supplier-funded customer program is one linked object producing two accruals per event, so the customer promise and the supplier funding never drift out of step. Purchase lines can be built up the same way as sales lines. And freight, broker or commission owed to a third party can accrue when your customer's goods ship, paid to the vendor through the same chain.