Exports reference
Export is the last stage: approved invoices leave InletAP and become bills in your ledger, or rows in a file your ledger can import. This page describes what is sent, what the statuses mean, and what happens when a posting fails.
Export is a deliberate act. Approving an invoice marks it ready and nothing more; somebody — or, in time, a schedule — starts the batch.
Connector kinds
| Kind | What it is | Availability |
|---|---|---|
quickbooks_online | A direct connection to a QuickBooks Online company. Approved invoices are created as Bills. | Every plan, including the free one |
csv | A mapped CSV file, downloaded from the export batch. | Every plan |
sftp | The same CSV, delivered to an SFTP destination you configure. | Pro and above |
There is no property management system connector. Xero, AppFolio, Buildium, Yardi and Rent Manager are served by the CSV, which they all import. It is less magical than a direct connector and it works everywhere, which on balance is a fair trade.
Connector states
| State | Meaning | What to do |
|---|---|---|
connected | Working. Batches can be posted. | Nothing. |
action_required | The connection has been rejected and cannot be renewed on its own — typically because the stored authorization was revoked or expired at the ledger's end. | Reconnect the company. Nothing posts until you do. |
disconnected | No live connection. | Connect it, or export by CSV in the meantime. |
A QuickBooks batch is refused before it is queued if the connection is not connected, or if the QuickBooks plan on the other end does not support bills at all. One clear sentence at the point of clicking is better than a batch full of parked invoices twenty minutes later.
Export statuses
Batches and the items inside them share the same four statuses.
| Status | Meaning |
|---|---|
pending | Queued. For QuickBooks this also covers the gaps between scheduled attempts, so a pending batch may have a post in flight. |
processing | A worker is running it now. |
succeeded | Every item completed. |
failed | The batch did not complete. Its documents move to failed_export. |
Each run of a batch records an attempt, with its start time, end time and any error payload. A batch that failed twice has two attempts against it, which is how you tell "it failed once and worked" from "it has been failing all week".
What is written to QuickBooks
Each approved document becomes one Bill:
| On the bill | From the invoice |
|---|---|
| Vendor | Your vendor, through its mapping to a QuickBooks vendor |
| Transaction date and due date | The invoice date and due date |
| Document number | The invoice number, truncated to the length QuickBooks allows |
| Lines | The extracted line items, each against the GL account its code maps to; where extraction found no line items, one line built from the document total |
| Class | The property, where the QuickBooks company tracks classes |
| Tax | The tax code on the document, where tax is stated |
| Private note | A marker identifying the InletAP document it came from |
The document records the external ID that comes back, so "where did this end up" always has an answer. The reverse is also true: the marker written into the bill's private note identifies the InletAP document, which is what makes reconciliation possible in both directions.
A split invoice on a bill
Where an invoice has been split across properties, the bill carries one line per allocation rather than one line per printed line item:
- The GL account is the allocation's own code.
- The class is the allocation's property, on that line. Class is a per-line field on a QuickBooks bill, which is what makes property splitting possible at all.
- The description is the vendor's own line text with the property name alongside it, so somebody opening the bill in QuickBooks can see which building each line is for.
- The location, if you use locations, is a header field for the whole bill and cannot vary by line.
Where the properties belong to ownership entities with separate QuickBooks companies, the document posts as one bill per company. See multi-entity QuickBooks.
Several checks run before any network call, and each of them parks the invoice rather than posting something wrong:
- The vendor has no QuickBooks mapping.
- A GL code resolves to no account.
- Line items do not add up to the invoice subtotal.
- The invoice states tax and no tax code is mapped to carry it.
- The bill would settle at a figure other than the stated total.
- The invoice is in a currency the QuickBooks company cannot hold.
Each parks with a message naming the figures involved. Posting a bill that is short by the tax is the kind of error nobody finds until a vendor chases the balance.
What the CSV contains
The default columns are the ones most ledgers ask for:
"invoice_no","vendor","due_date","amount","property","gl_code","status"
Every cell is quoted, including the header row, which keeps a vendor name containing a comma from becoming two columns.
The mapping is configurable. A column has a header, written verbatim to row one, and a source: the document record — its id, its status, its vendor or its property — or any extracted field by name. That last option is the escape hatch that stops the list being closed: if your ledger wants the purchase order number in column three, it can have it.
Change the mapping to match your ledger's import template rather than editing files after the fact. A CSV that imports cleanly on the first attempt at month end is worth ten minutes of setup in a quiet week.
One row per invoice, or one row per allocation
A CSV has a granularity setting, and it matters the moment you split an invoice across properties.
| Granularity | What a row is | Use it when |
|---|---|---|
document | One row per invoice | The default, and correct for every workspace that does not split. |
allocation | One row per allocation | You split invoices and your ledger needs each property's share on its own row. |
The default is document so that an existing downstream import keeps working byte-for-byte. Nobody's month end breaks because a new setting appeared.
The reason to change it is simple: a document-granularity row has one property cell, and a three-way split has three properties. One cell cannot honestly hold them. At allocation granularity each allocation becomes its own row, repeating the invoice-level values, which is the shape every ledger's import expects for a distribution.
At allocation granularity these column sources become available alongside the document ones:
| Source | What it writes |
|---|---|
allocation_property | The property this row is coded to. |
allocation_entity | That property's ownership entity. |
allocation_gl_code | The GL code on this allocation. |
allocation_amount | This allocation's amount. |
allocation_percent | Its share of the line it splits. |
allocation_seq | Its position within the split. |
allocation_of | The printed line the split belongs to. |
The rendered file is kept on the batch and stays downloadable, including when an SFTP delivery afterwards fails.
Retries
Only a failed batch can be retried. A batch that is pending, processing or already succeeded is refused, with the reason.
For QuickBooks a retry is a replay rather than a second post. The request identifier minted for the first attempt is reused, so Intuit recognizes the repeat and returns the original bill instead of creating another one. This is the single most important behavior in the export path: the failure mode it prevents is paying a vendor twice.
Transient faults — throttling, a timeout, an internal error at the far end — are retried on a backoff of a few seconds, up to a small fixed number of attempts. Faults that cannot succeed unchanged, such as a rejected account reference, are parked immediately with the code recorded, because retrying them only burns your rate limit.
A failed export leaves its documents in failed_export. Fixing the cause and retrying moves them back through approved and out again.
A document that fans out across several QuickBooks companies can fail in only some of them. Two bills posted and one parked is the partially_exported status, and the retry is scoped to the target that failed — the bills that posted are not touched, and each bill carries its own request identity. See export failures.
Where to go next
- Connecting QuickBooks — the connection itself, step by step.
- Month-end export — the routine this reference sits underneath.
- Export failures — when a batch will not go.
- Invoice statuses — what
exported,partially_exportedandfailed_exportmean for a document. - Multi-entity QuickBooks — one invoice, several companies, several bills.