QuickBooks Invoice Creation
Turn app transactions into QuickBooks invoices with the right customer, items, and tax.
What it adds
Server-side creation of an invoice in the connected accounting company from an app transaction, with the external reference stored.
What your agent is told to do
5
What your agent is told to do
5-
1
Resolve the customer before building the invoice: look up the stored external reference first, then attempt a deliberate match, and create a new customer only when neither finds anything.
-
2
Require an explicit mapping from each app product or charge to an income item and a tax code in the connected company. Do not guess a default account, because the wrong account is an accounting error someone has to unwind by hand later.
-
3
Compute totals as exact decimals under one defined rounding rule, and reconcile the app's total against the total the provider returns before marking the transaction synced.
-
4
Store the returned invoice identifier and its version against the app transaction and use them for every later read or update. Xero Invoice Sync solves the same problem for a different ledger, so keep customer matching, queueing, and reconciliation in one shared path and vary only the provider adapter.
-
5
Run the whole exchange server-side under the workspace's stored credentials, refreshing an expired token before the call and prompting for re-authorization when the refresh fails. Never place accounting credentials anywhere the browser can read them.
Edge cases it handles
8
Edge cases it handles
8- Two app records for the same real customer must not produce two ledger customers. Match deliberately, and when the match is ambiguous surface it rather than creating a second entry an accountant has to merge.
- An item or tax code made inactive in the accounting system is rejected on use. Validate the saved mapping against the company's current lists before sending, and name the stale mapping to the operator.
- Rounding differences of one cent per line become real discrepancies at volume. Apply rounding at one defined point and refuse to post an invoice whose total does not match the app's.
- The provider rejects an update that carries an outdated version of the object. Re-read the invoice, reapply the change, and retry once rather than forcing the write through.
- A closed accounting period refuses a posting outright. Report that to the operator as a period problem with a suggested date, not as a generic sync failure.
- Without the stored invoice reference, a retried job creates a second invoice for the same transaction. Write the reference in the same transaction that marks the app record as sent.
- Payments, credits, and voids applied inside the accounting system must flow back to the app, or the app will keep showing an invoice as outstanding long after it was paid.
- When the provider is unavailable the app transaction must still complete. Queue the invoice, show it as pending, and never block a customer-facing action on an accounting write.
Definition of done
9
Definition of done
9- Each app transaction produces exactly one invoice, even when the creation job is retried.
- Customers are matched before creation, and ambiguous matches are surfaced rather than duplicated.
- Every synced product or charge has an explicit income item and tax code mapping, validated against the company's current lists.
- Invoice totals reconcile exactly with the app's totals, with rounding applied at one defined point.
- Version conflicts and closed-period rejections produce specific, actionable operator messages.
- Credentials refresh server-side and are never exposed to the browser.
- A provider outage leaves invoices queued and visible as pending without failing the originating transaction.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Lemon Squeezy License Sync
Lemon Squeezy License Sync
Sync Lemon Squeezy orders and license keys into the app's entitlement state.
What it does
A verified event pipeline mapping Lemon Squeezy orders, subscriptions, and license keys onto local entitlements, with activation limits and revocation handled.
How it works
- 1 Verify the authenticity of every incoming provider event before it changes anything. An unverified purchase notification is a request from the internet to give away your product.
- 2 Keep an explicit server-side table mapping each purchasable variant to the entitlement it grants. Do not infer the plan from a product name, because names get edited for marketing reasons and entitlements should not move when they do.
- 3 Bind each license key to a single account on first activation and refuse to activate it against a different one afterwards, with a documented path for an operator to release a key that genuinely needs to move.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/lemon-squeezy-license-sync
Stripe Customer and Subscription Sync
Stripe Customer and Subscription Sync
Keep local billing state matching Stripe as subscriptions, invoices, and plans change.
What it does
A verified event pipeline that projects Stripe customer, subscription, and invoice state onto the app's own access records, with reconciliation for anything the pipeline missed.
How it works
- 1 Define one local projection of billing state per account: which plan, which status, which period it runs to, and whether access is currently allowed. Every entitlement check in the app reads that projection and nothing else.
- 2 Verify every incoming event as genuinely from the provider before acting on it, and record its identifier so a replay is recognised and ignored. Providers retry on any non-success response, so handlers must be safe to run repeatedly.
- 3 Store a timestamp or version with the projection and refuse to apply an event that is older than what has already been written. Events arrive out of order, and a stale cancellation overwriting a fresh renewal locks a paying customer out.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/stripe-customer-and-subscription-sync
Shopify Order Import
Shopify Order Import
Import Shopify orders into the app with money, fulfilment, and later edits accurately kept.
What it does
A resumable import of the connected store's orders, mirroring line items, discounts, taxes, and fulfilment state locally.
How it works
- 1 Separate the initial backfill from the ongoing feed. The backfill walks history in a stable order behind a resumable cursor; the feed applies live updates as they arrive.
- 2 Key every imported order on the shop identifier together with the store's own order identifier, so re-running the import updates existing rows instead of duplicating them.
- 3 Store money as an exact decimal with its currency alongside it, and keep both the shop currency and the presented currency where they differ. Do not convert to a single display currency on the way in, because the original amounts cannot be recovered afterwards.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/shopify-order-import
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.