Accounting in the same workspace as the bench

A lot of shops run their books in a separate accounting package and move numbers across by hand at the end of the month. erp.io Accounting is the ledger inside the suite: a chart of accounts, journal entries that post and void properly, customers and invoices, vendors and bills, payments against both, and aging for what you are owed and what you owe.

Money is stored as whole cents, never as a floating-point number, and every change is written to a hash-chained audit trail that records what changed and who changed it. That is the part of accounting that is easy to get subtly wrong, and it is the part the module is built around.

It is designed to be the ledger Service posts into. Service invoicing is live, but it does not post here yet. When the accounting sync is built, an invoice issued on a repair, a payment received, a refund and the cost of parts used will each post to Accounting through a write API, once, with no double counting.

Your two biggest suppliers send bills every week, and some offer a discount for paying early. Those bills go into Accounting as bills against a vendor, and the payables aging tells you what is due this week. Your bank account feeds in overnight, posting rules handle the recurring lines like the card processor deposit and the rent, and the rest waits for you to categorize.

The fixed-asset register holds the things that wear out slowly: the service van, the wheel-truing and frame-facing tools, the shop refit. Depreciation schedules run on their own. Deferred revenue schedules suit prepaid service plans, where a rider pays in March for a year of tune-ups and the income belongs to the months the work happens.

At the end of the month, the close is not a pile of tasks. It is a list of checks, such as the bank being reconciled to zero difference, that have been running every night already. When they all pass, the month can close.

The Service plan settles who owns what. Service owns repair invoices, and will own deposits and statements, because they come from the work. Accounting will own the ledger, and gets a write endpoint so Service can post invoice issued, payment received, refund, write-off and parts cost as they happen. Each posting carries a key so it lands exactly once.

That write endpoint does not exist yet; the public Accounting API is read-only today, and building the write side is a prerequisite for Service invoices posting to the ledger. Pey then sits across both: it matches the payments Service records to the deposits that show up in your bank feed.

Two limits worth knowing. Invoices raised in Accounting itself are records in the ledger: Accounting does not email them, produce a PDF for the customer or attach a pay link. And sales tax is entered as a figure on the invoice rather than calculated from a rate table. Service invoices do not send anything yet either: marking one sent changes its status, with no email or PDF for the customer. Customer delivery and card payment are planned inside Service.