标签：#accounting

I built a small manufacturing company end-to-end inside an SAP S/4HANA sandbox — one plant, one product, one month — specifically to watch what the month-end close does to a margin that looks healthy at billing time. Every number below comes from an actual document in that system. At billing, the month looked good Revenue 20,000 COGS at standard 12,800 Margin 7,200 = 36% Three days later, after the close, the same month landed at 1,200 = 6% . Nothing was posted incorrectly. Three gates took the 30 points, in this order. Gate 1 — Cost center revaluation (KSS1 / KSII) The planned price for the labour activity type was derived the usual way: planned cost divided by planned activity quantity. Production orders consumed hours at that planned rate all month. Then the actuals arrived. Depreciation posted 9,000 against a plan of 3,000 . Activity quantity did not move. So the actual activity rate came out at roughly three times the planned rate, and every hour any order had already consumed became retroactively more expensive. This is the part that surprises people: the damage was decided weeks earlier, in a transaction nobody files under "costing decisions" — planning the activity price. Gate 2 — Order variance (KKS1 / CO88) With the revalued rate applied (CON2), the production orders no longer settled clean. The difference split across variance categories and settled to variance accounts — not into inventory. That distinction matters. If it went to inventory, it would sit on the balance sheet until the goods were sold. It doesn't. It is parked, waiting for the next step. Gate 3 — Actual costing (CKMLCP) This is the step people forget, and it is where the margin actually dies. The actual costing run rolls the variance into the material's periodic unit price, and then moves the portion belonging to what was already sold into COGS. Before this run, the P&L still looked fine. After it, the 6,000 that had been sitting in variance found its way onto the income statement. What I

I run agents for many customers, on my own infrastructure, and I pay for every token they burn. You...

reconmatch is a local-first transaction matching engine for accountants, bookkeepers, and controllers. Two CSVs in — books vs bank, invoices vs payments — a scored, auditable match report out. No account, no upload, no network call. Repo: github.com/SybilGambleyyu/reconmatch The unglamorous pain If you close books for a living, you already know the scene: two windows open, a bank CSV on the left, a general-ledger export on the right, and an afternoon disappearing into "which deposit is which invoice." Bank feeds help until they do not. The hard cases are ordinary: One deposit that covers three invoices Two payouts that sum to one sales batch on the books A check number in the memo on one side and a dedicated column on the other "ACH ACME CORP INV 1042" vs "Invoice payment ACME Corp" An orphan the feed never explained Enterprise close tools charge enterprise prices and want the data in their cloud. For a CPA firm or bookkeeper sitting on confidential client ledgers, "just upload the CSV" is often a non-starter. Spreadsheet VLOOKUP falls over on partial payments and batch deposits. What reconmatch does Matching runs in deterministic phases so the same inputs always produce the same proposals: Exact / reference-strong — amount within tolerance, date in window, shared invoice/check/wire token Amount + date — numbers line up even when memos are noise Fuzzy description — token overlap plus sequence similarity (pure Python stdlib) Group 1:N and N:1 — one line equals the sum of several on the other side Every accepted match carries a score and human-readable reasons suitable for a workpaper. Unmatched lines stay unmatched — the tool does not invent a story for them. pip install git+https://github.com/SybilGambleyyu/reconmatch.git reconmatch books.csv bank.csv -o ./march-recon Outputs: plain-text report, matches CSV, unmatched CSV, and full JSON. Zero required third-party dependencies. Python 3.10+. Library use from reconmatch import MatchConfig , match_transactions from rec