Skip to main content

Overview

In a trade business the price on an order line is not one number. It is a base, a premium over that base, and deal money the customer will claim back months later. Finance & Operations stores a single unit price. The decomposition that says how much of that price is a future liability lives somewhere else, usually a spreadsheet kept by whoever negotiated the deal, and the ERP invoices a number it cannot explain.

The native trade modules are real, and they model allowances off the price. They do not build deal money into the invoiced price, they accrue at invoice rather than when goods ship, and they reference the agreement live, so an agreement edited in March quietly restates an order accepted in January. Deal money ends up being the largest liability on the balance sheet that the ERP does not actually govern.

What Earmark does instead​

Earmark turns deal money into a governed object, inside Finance & Operations:

  • A deal is approved before it can cost anything. Deals ride native workflow with segregation of duties seeded as rules: the author cannot approve, and the deal approver cannot approve claims.
  • The price is built, and then frozen. An accepted line carries base plus over-basis plus deal money, grossed into the invoiced price or carried as an allowance, snapshotted at acceptance. A deal amended later applies to new lines only. A line that changes after pricing is flagged stale, never silently repriced.
  • Accruals post when goods move. At shipment, invoice or on demand, as a real journal in the deal's currency, after the native document has committed, so a shipment is never blocked by finance configuration.
  • Controls are enforced, not reported. Lifetime cap, per-transaction limits and quantity thresholds are checked against a balance kept in the same transaction, with headroom alerts to the deal owner and a control workspace that shows every deal's position without running anything.
  • Claims are documents. Generated from claimable accruals, approved by workflow, credited to the customer's invoice account, and settled in standard accounts receivable. A claimed accrual cannot be claimed again. A customer claim statement proves the balance from the ledger's own records.
  • The vendor side runs on the same engine. Supplier rebates accrued at goods receipt, supplier-funded customer programs as one linked mirror with two accruals per event, purchase price build-up, and freight, broker or commission accrued at customer ship and paid to the vendor.

Earmark installs as one package beside native Trade Allowance Management and Rebate Management without extending, wrapping or reading either. It uses Finance & Operations for what it already does well, workflow, posting, number sequences, dimensions, currency revaluation and security, and adds only what native lacks. Run it free in a sandbox: see Get started. The model is described in Concepts.

What's included​

  • Deal object with Table / Group / All targeting and native workflow approval
  • Segregation of duties between deal author, deal approver and claim approver
  • Price build-up: base + over-basis + deal money, gross-up or off-invoice, frozen on commit
  • Accrual at shipment, invoice or manual, posted in deal currency, revalued or rate-locked
  • Lifetime cap, per-transaction and quantity thresholds, enforced live with headroom alerts
  • Deal control workspace with execution exceptions and an unaccrued-transactions safety net
  • Claims as governed documents, credited to the customer, settled in standard AR
  • Customer claim statement and accrual-to-GL reconciliation
  • Vendor shapes: supplier rebates, supplier-funded mirror, purchase build-up, third-party accruals
  • Coexists with native Trade Allowance and Rebate Management, verified at build time