--- name: finance-for-integrators-checks description: 18 rules from the Noesa course "Finance for Integrators". For backend devs automating an online store's billing — invoices, payments, refunds, payouts — and the finance behind each. --- # Finance for Integrators — the rules Use with: Claude Code or Claude (save as a skill), Cursor (save under .cursor/rules as .mdc), ChatGPT or any other assistant (paste the text below into custom instructions or a project's instructions). 18 rules, taken from the course at https://noesa.leafsoft.online/c/finance-for-integrators Each heading is one thing the course teaches. Most are checks to run on your own output before presenting it as done; a few are background you are expected to have. 8 also name a mistake models make by default, under "Watch for". Apply these to the thing you are producing — the type, the schema, the query, the copy — not only to how you explain it. Where a rule names a field, a format or an identifier, that name belongs in the output. ## The money story: from a sale to the books Trace a license sale through the teams that touch it, in order, so you know where your integration sits and who owns each decision after it. **Watch for:** If you asked an AI to assign each billing decision to a team, what would it likely get wrong? It can produce a polished version of the common ownership map, but it cannot know the company's actual boundaries from the task alone. Your company may let the store issue invoices, route tax through a person, or put refunds under a different approver. Treat the proposed map as a hypothesis: verify every owner with the team before you encode it. ## Reading the ledger without building one Read any accounting entry and say what moved where — enough to follow a finance conversation, without ever needing to post one yourself. ## Five account types and the one equation Classify any account into one of five types, and predict which direction — debit or credit — increases it. ## Accounts Receivable, from order to cash Follow an invoice from order to cash in both the prepaid and the invoiced flow, and name what Accounts Receivable owns at each step. ## Revenue recognition and deferred revenue Explain when a license sale becomes income, and why cash you collected isn't yet revenue you've earned. **Watch for:** If you asked an AI to book a prepaid annual sale, what tempting mistake might it make? It may default to the common cash-in-equals-revenue pattern and recognize the full payment immediately. It does not know the company's performance obligation, term, or change dates unless you supply them. Check that the proposed treatment follows delivery and leaves the unearned amount in deferred revenue. ## Invoices, credit notes, and adjustments Say why a correction is a credit note or a reversing entry, never an edit, and what that means for the data your store keeps. **Watch for:** If you asked an AI to fix a wrong posted invoice, what unsafe shortcut might it choose? It may reach for the shortest working data change: update the amount in place, or call every correction a refund. That loses the original record and ignores whether cash moved. Require a new event linked to the original, then let AR or finance choose credit note, reversal, void, or refund. ## Accounts Payable: the other side of the money Describe what Accounts Payable does and name the two store events — refunds and partner payouts — that flow through it, so you know which team owns money leaving Meadow. ## Tax I: sales tax, VAT, and GST Put the right consumption tax on an invoice — India GST, EU VAT, or US sales tax — from customer country, selling entity, and product classification. **Watch for:** If you asked an AI to choose the tax for this sale from the customer's country alone, what would it miss? It may return the common country rate while missing the selling entity, B2B/B2C status, product classification, location evidence, and the rate in force on the invoice date. Those facts can change the treatment entirely. Supply them to the approved tax engine and verify the frozen tax line instead of trusting a plausible rate. ## Tax II: cross-border, withholding, and e-invoicing Explain the three things that change when a sale crosses a border — withholding tax, reverse charge, and e-invoicing/clearance mandates — and what each demands from your store data. ## Multiple legal entities and inter-company Explain why one business runs several legal entities, and apply the rule that decides which Meadow entity should invoice a given customer. **Watch for:** If you asked an AI which company entity should invoice a customer, what would it likely assume? It may choose the geographically nearest entity or a familiar country-routing pattern. It cannot infer the company's registrations, banking arrangements, product exceptions, or finance-owned policy. Check the answer against the explicit entity-selection rule; a sensible-looking guess can change tax, currency, invoice numbering, and legal ownership at once. ## Multi-currency: one sale, two numbers Handle a sale made in the customer's currency and explain where exchange differences come from between invoicing and payment. **Watch for:** If you asked an AI to convert the euro invoice into rupees, what policy choice might it hide? It may use the most available rate, such as today's spot rate, without asking for the company's official source, the correct valuation date, or the entity's functional currency. Preserve the original amount and timestamps, then verify every converted figure against finance's rate policy; arithmetic can be correct while the accounting basis is wrong. ## Reconciliation: books vs bank vs gateway Explain what bank and payment-gateway reconciliation prove, and why clean, idempotent store data is what makes both possible. ## Periods and close Explain what an accounting period is, what "closing" and "locking" a month or year mean, and why your store's timestamps decide a sale's period. **Watch for:** If you asked an AI which period a late event belongs to, what date might it choose too quickly? It may use the processing or arrival timestamp because that is the field in front of it, missing the true business date, time zone, close calendar, and cut-off policy. Check the event date against finance's rules before assigning the period; a technically accurate queue timestamp can still move revenue into the wrong month. ## The report map Map which report each finance team lives in, what's specific to one team, and what's shared — so you know who reads the store facts you emit, and where. ## Revenue reporting Read a revenue report and distinguish billed, recognized, and collected revenue, and read revenue split by product, entity, and country. ## Tax filing reports Name the main tax-filing reports per jurisdiction — India's GSTR-1/3B/2B, the EU VAT/OSS return, and TDS/withholding — and state what store data each is built from. ## Audit and compliance Explain what an audit verifies and name the non-negotiables your store integration must preserve so an independent stranger can trust the books. **Watch for:** The original record was overwritten, and you ask an AI to rebuild the audit trail. What can it never promise you? It can produce a convincing chain from the records that remain, but it cannot recover lost provenance or prove that an invented link matches what originally happened. Verify stable ids and immutable source records before trusting the narrative. Once the original evidence is gone, fluent reconstruction is not an audit trail. ## Capstone: one sale, end to end Trace one cross-border license sale — prepaid German customer and invoiced Ridgeline — through every team and report, and leave with the decision checklist that makes you autonomous.