Invoices, payments and parts that land in the ledger

In most shops the service system and the books are two products joined by a sync that breaks every few months. Invoices get duplicated, payments land on the wrong day, and the month-end reconciliation becomes a Saturday of its own.

erp.io is built the other way. Service owns the work and the invoice; Accounting owns the ledger, the chart of accounts and the financial reports. Service never keeps its own chart of accounts. Instead, every event that moves money is posted from Service to Accounting as it happens.

That is the plan (decision D2). Accounting is live. The piece that is not built is the write connection itself: today Accounting's API is read-only, and the endpoint Service will post to has to be built on Accounting's side. Until it is, enter Service invoices in your books as you do today; the monthly Service report gives you the invoiced and collected totals to check against.

The failure that ruins accounting syncs is double posting. A network hiccup, a retry, and the same invoice is in the books twice. The Service design puts an idempotency key on every posting, made from the record and the event, such as an invoice and "issued". Accounting records each key once and ignores repeats.

Postings are also authenticated. Service signs each request as a service, short-lived and bound to the exact content being sent, so nothing else can post to your ledger by pretending to be Service.

And posting happens outside the customer's request. Service writes the event to an outbox and delivers it separately, so a slow moment in Accounting never makes the counter wait on a payment. Service already uses this outbox pattern for checklist deliveries today.

Parts are where bike-shop books usually go wrong, because nobody records cost when a part leaves the shelf. When inventory ships, Service will hand perpetual cost to Accounting as parts are consumed on work orders, so cost of goods sold reflects what actually went onto bikes that month. Accounting already has the weighted-average costing to receive it.

Payroll is prepared, not run. Service will compute approved hours and overtime from time tracking and export them to your payroll provider, and post a payroll accrual journal to Accounting. It does not pay people or file taxes.

On the bank side, erp.io Pey is live and matches payments to the deposits they arrive in, so a Stripe payout that bundles twenty pickups is matched to those twenty invoices rather than left as one unexplained line.