Double-entry by default
Accounting impact is represented as balanced journal entries. Debits and credits must net to zero before an entry is accepted.
Accounting Model
How LedgerLine turns app activity into double-entry accounting.
Connected apps send operational objects like customers, estimates, invoices, payments, vendors, bills, vendor payments, and documents. LedgerLine turns eligible posting and reversal actions into balanced accounting records, while keeping drafts, documents, reports, and setup metadata operational.
Posting creates impact
Operational records such as draft invoices, estimates, bills, and vendor payments do not affect accounting until an explicit posting action runs.
Reversals preserve history
LedgerLine creates reversing journal entries instead of deleting or rewriting original posted history. Original journals remain visible and auditable.
Reports read posted state
A/R, A/P, ledger, P&L, balance sheet, and 1099 support views are read-only summaries over posted records and journal entries where implemented.
Money-In Model
Customers, estimates, invoices, and payments.
Money-in workflows become accounting only when invoices are posted or payments are recorded against posted receivables.
| Event | Accounting impact | Notes |
|---|---|---|
| Customer created | No accounting impact | Customer records identify the counterparty for future invoices and payments. |
| Estimate created | No accounting impact | Estimates are operational sales documents. |
| Estimate accepted or declined | No accounting impact | Acceptance changes estimate workflow state, not the ledger. |
| Estimate converted | No accounting impact | Conversion creates a draft invoice. Accounting starts only when the invoice is posted. |
| Invoice created | No accounting impact | Draft or operational invoice creation does not touch the ledger. |
| Invoice posted | Dr Accounts Receivable, Cr Revenue | Posting creates the customer receivable and revenue entry. |
| Payment recorded/applied | Dr Cash or Clearing, Cr Accounts Receivable | Customer payment reduces A/R. Payment creation does not create revenue. |
| Payment reversal/refund | Dashboard/full-refund foundation where implemented | Posted payment reversal/refund restores invoice balances through reversing entries. Public refund/reversal APIs, partial refunds, disputes, and processor refund calls remain deferred. |
Money-Out Model
Vendors, bills, A/P, and vendor payments.
Money-out workflows become accounting through explicit bill posting, bill reversal, vendor payment posting, and vendor payment reversal.
| Event | Accounting impact | Notes |
|---|---|---|
| Vendor created | No accounting impact | Vendor records identify the counterparty for bills and vendor payments. |
| Bill created | No accounting impact | Draft/open bills are operational until posted. |
| Bill posted | Dr Expense, Cr Accounts Payable | Posting recognizes expense and the vendor liability. |
| Bill reversed | Dr Accounts Payable, Cr Expense | Bill reversal creates a reversing journal entry. Bills with active vendor payment allocations must have those payments reversed first. |
| Vendor payment created | No accounting impact | Draft/ready vendor payments and allocations are operational until posted. |
| Vendor payment posted | Dr Accounts Payable, Cr Cash/Bank/Clearing | Posting pays down the vendor liability and reduces the selected cash, bank, or clearing account. |
| Vendor payment reversed | Dr Cash/Bank/Clearing, Cr Accounts Payable | Reversal restores A/P and cash/bank/clearing through a new reversing journal entry. |
Example Ledger Entries
What posting writes to accounting.
| Event | Accounting entry | Notes |
|---|---|---|
| Post invoice | Dr A/R, Cr Revenue | Creates customer receivable. |
| Record payment | Dr Cash/Clearing, Cr A/R | Reduces receivable. |
| Post bill | Dr Expense, Cr A/P | Recognizes vendor liability. |
| Post vendor payment | Dr A/P, Cr Cash/Clearing | Pays vendor liability. |
| Reverse bill | Dr A/P, Cr Expense | Reverses bill expense and liability. |
| Reverse vendor payment | Dr Cash/Clearing, Cr A/P | Restores payable and cash/clearing position. |
Documents And Reports
Evidence supports accounting, but does not create it.
Documents and evidence files can support transactions, invoices, estimates, bills, vendors, customers, and CPA/export packages. Files remain private and server-routed. Uploading, linking, reviewing, sharing, or archiving evidence does not create journal entries by itself.
A/R Summary
Reflects posted invoices less applied customer payments. Unposted invoices and non-accounting estimates are excluded.
A/P Summary
Reflects posted bills less posted, non-reversed vendor payment allocations.
1099 Summary
Uses posted, non-reversed vendor payments for tax-support reporting. It is not IRS filing, e-filing, payroll, or tax advice.
Ledger Reports
General Ledger, Trial Balance, Profit and Loss, and Balance Sheet views are generated from posted journal entries where implemented.
API Boundary Model
API calls are scoped and explicit.
- Creating operational records is different from posting accounting records.
- Public APIs expose create/list/read/update and post/reverse actions where those workflows are built.
- API keys determine organization, connected app, and test/live environment.
- Client-submitted trusted scope fields such as organization_id, connected_app_id, app_environment_id, environment, and mode are rejected.
- The API Reference is read-only and never sends live requests or asks for real API keys.
External Provider Boundary
Core accounting is provider-neutral.
- Core accounting does not require Stripe, SendGrid, Plaid, OCR/AI, IRS e-filing, or payroll providers.
- Stripe Checkout/payment collection remains deferred unless implemented later.
- SendGrid real email sending remains deferred unless implemented later.
- Plaid bank feeds remain deferred.
- OCR/AI parsing and automatic accounting from uploaded documents remain deferred.
- IRS e-filing and payroll/HR remain deferred.
Where To Go Next
Pair the model with implementation docs.
Get Started
Follow the public setup/testing path before creating real records.
API Recipes
Use server-side workflow examples that reference these accounting boundaries.
Security
Review API-key safety, private storage posture, rate limits, and production gates.
Integration Guide
Review API auth, first calls, webhooks, errors, and current product boundaries.
API Changelog
Review versioning, deprecation, OpenAPI, SDK, webhook, and compatibility policy.
API Reference
Browse read-only fake request and response examples.
AI Install Prompt
Prompt AI coding tools to wire LedgerLine safely with server-side keys.
Developer Docs
Return to the main public developer documentation hub.
OpenAPI YAML
Use the manual OpenAPI route reference for the current public API surface.
Production Boundary
This page explains behavior. It is not production approval.
LedgerLine is ready to enter setup/testing from the code side. Production still requires operator setup, migrations, private buckets, RLS/Storage dry-run, smoke/security QA, and rollout planning.