Accounting · Miami
Cross-border invoicing across five jurisdictions
The firm went from assembling every invoice by hand to flagging entities and triggering a batch.
Stack
- Airtable
- QuickBooks API
- n8n
- JavaScript
- ~1,600
- entities administered by the firm
- 1,000–1,200
- invoices a year, previously assembled by hand
- 35
- invoices in the first batch across three new jurisdictions, zero errors
- 37
- records with inconsistent spellings normalized before the first run
The workflows
01Invoice batch
- Entities flagged in Airtable
- Assemble by jurisdiction and contracted services
- Create in QuickBooks, numbering respected
- Send to the current contact
- Write number and status back
02Payment confirmation
- Payment reconciled against its invoice
- Compute outstanding balance
- Notify the client, balance included
The problem
A Miami accounting firm administering around 1,600 international entities issued its invoices by hand, almost all of them concentrated in a single January season.
One person loaded the amounts for each entity into a spreadsheet. Another built every invoice in the accounting system line by line: the jurisdiction renewal, the entity filing, the partners’ personal filings. Then emailed it, and went back to mark the spreadsheet again.
Every jurisdiction has its own rules. Every entity has its own mix of contracted services. And the contact emails were kept current in the operational database, not in the accounting system.
The process worked. It just consumed weeks of skilled work on copying, with the margin of error that implies.
The approach
Built in two phases. The first automated the highest-volume circuit. The team flags the entities in Airtable and fires the batch; the system assembles each invoice from that entity’s form type and contracted services, creates it in the accounting system respecting numbering, sends it to the correct contact, and writes the invoice number and status back to the base.
Payment confirmation went automatic in the same phase: when the firm reconciles an incoming payment against its invoice, the client is notified without anyone drafting it.
The second phase added three jurisdictions with different logic — two bill renewal only, the third behaves like the continental states — plus partial payment handling. The operational base now reflects amount invoiced, amount collected, outstanding balance and invoice status, sourced from the accounting system as the source of truth.
All development ran against an isolated environment: a sandbox company and a copy of the operational database. Nothing touched production until it had been validated layer by layer — assembly logic, then creation, then delivery, then the full circuit end to end.
The decision worth copying
Before extending anything, I audited the system that already existed. That is where the edge cases live when a circuit grows: entity names with special characters, clients with several contact emails, jurisdictions written inconsistently, duplicate events.
Thirty-seven records with spelling variants in the jurisdiction field were normalized before the first run.
That prior review is the reason a large batch goes out without surprises.
The result
The first run on the three new jurisdictions was thirty-five invoices in a single batch, with no errors. The two highest-volume jurisdictions now go out in batches of fifty and one hundred.
Partial payments, previously visible only by opening the accounting system, now show in the operational base with their outstanding balance.
Delivered with full technical documentation, an operating guide, and a year-end changeover checklist, so the team runs the system without external support.
The transferable piece
Automating is not replacing professional judgment. It is taking the mechanical part off the team so that judgment gets applied where it matters.
Who to invoice and when is still the firm’s decision. What stopped being human work is assembling each invoice, finding the right contact, sending it, and noting that it was sent.