Weel
Australian card spend and approved reimbursements from Weel, coded to the GL account you mapped and posted with GST on its own tax line. Your card-payable balance reconciles to the Weel statement instead of being rebuilt from an export.
Overview
Australian card spend arrives with GST attached, a budget it was drawn against, and a category that someone still has to turn into a GL account. Weel controls the spending and the approvals. DualEntry owns the ledger the spending has to land in. The connector between them does the coding.
A new or settled card transaction in Weel, or an approved expense, triggers the sync. The connector retrieves the record, applies your category-to-GL and team-to-dimension mappings, then posts the result to DualEntry: the net expense debits the mapped GL account, the Weel card-payable account is credited, and the GST posts as its own tax line at the amount and rate Weel recorded. The Weel transaction ID lands in the external reference field, the merchant becomes the line description, and the cardholder maps to an employee or vendor reference. At settlement, each posted transaction is matched to the Weel card statement so the card-payable balance in DualEntry reconciles to Weel.
The flow is inbound only: Weel spend moves into DualEntry, and DualEntry does not push your chart of accounts or journal entries back to Weel. Weel stays the source of truth for the transaction itself, the cardholder, the budget and the GST on it. DualEntry stays the source of truth for the chart of accounts, tax treatments and the posted ledger. Edits made in Weel post as adjustments rather than duplicates, so the DualEntry balance tracks the current state of the Weel transaction.
This connection is delivered by APIWorx, a managed integration platform that sits between Weel and DualEntry and runs the connector as a managed service on its own infrastructure. There is no Weel connector tile inside the DualEntry application, and mapping and sync settings are maintained through APIWorx rather than in DualEntry.
Card transactions
Card refunds and adjustments
Approved employee expenses and reimbursements
Weel categories and budgets
Weel teams
Cardholders
GST and tax amounts
Card settlements and statement matches
Data synced
The integration syncs the following data types:
- Each Weel card purchase posts to DualEntry debiting the mapped expense GL account and crediting your Weel card-payable account
- The Weel transaction ID lands in the DualEntry external reference field and the merchant or description becomes the line description
- The Weel transaction date becomes the posting date and the transaction currency carries through onto the DualEntry entry
- The cardholder on the transaction maps to the DualEntry employee or vendor reference, and the team maps to a department or project dimension where that mapping is configured
- A new or settled card transaction triggers the sync, near real time where Weel webhooks are available and on a configurable batch schedule otherwise
- A refund in Weel posts as an adjustment entry that reverses the original charge against the same expense and card-payable accounts
- Edits made in Weel after a transaction has already posted come through as adjustments rather than duplicate entries
- The DualEntry balance therefore tracks the current state of the Weel transaction rather than the version that first posted
- Adjustments carry the same Weel transaction ID as the original charge, so both sides remain traceable to one source record
- An approved expense or reimbursement in Weel posts to DualEntry as an expense entry, with approval in Weel acting as the trigger
- Each entry is attributed to the cardholder who submitted it and to the Weel budget the spend was drawn against
- Reimbursement entries carry through to your AP and GL workflows the same way a manually entered card expense would
- The expense posts to the GL account mapped to its Weel category or budget, with any GST on a separate tax line
- The connector reads the GST amount and rate on the Weel transaction and posts a matching tax line in DualEntry
- The GL account mapped to the category receives the net expense and the mapped tax treatment receives the GST, so tax is never rolled into the expense amount
- Weel is an Australian platform and most transactions include GST, so your DualEntry tax treatments must be configured before mapping begins
- If a transaction's GST does not match what the mapped treatment expects, the connector raises a tax mismatch exception instead of posting a figure that would not reconcile
- Handling for foreign-currency transactions is confirmed during setup alongside the GST configuration
- Every Weel category or budget is mapped to a DualEntry GL account, so the target accounts must exist in your chart of accounts before mapping begins
- A Weel category or budget with no mapping posts to a default holding account and is flagged rather than blocking the sync
- Adding the missing mapping in APIWorx and reprocessing the flagged transaction moves it to the correct account
- Chart of accounts changes do not sync automatically: when you add a GL account or restructure budgets in Weel, update the corresponding mapping in APIWorx
- All mappings are maintained in the APIWorx portal rather than inside the DualEntry application
- Each Weel team maps to the corresponding DualEntry department or project dimension when you track spend by dimension
- This mapping step is optional: transactions still post without it, just without dimensional detail on the entry
- Once mapped, every posted card transaction and reimbursement carries its Weel team through as the department or project dimension
- Each posted transaction is matched to the Weel card statement and settlement so the card-payable balance in DualEntry reconciles to Weel
- Settlement events in Weel drive the reconciliation match, rather than a manual month-end comparison of statement to ledger
- A transaction amount or GST figure that does not match the Weel statement is flagged as an exception for review instead of posting silently
- Failed postings are logged with the Weel transaction ID and retried automatically under the connector's retry policy, with persistent failures flagged for manual review in the APIWorx portal
Key Features
- GST on its own line
The connector reads the GST amount and rate on each Weel transaction and posts a matching tax line in DualEntry. The mapped GL account receives the net expense and the tax treatment receives the GST, so tax is never rolled into the expense figure. - Categories and budgets mapped once
Every Weel category or budget is mapped to a DualEntry GL account and reuses that mapping on every transaction. A category with no mapping posts to a default holding account and is flagged rather than blocking the sync. - Teams as dimensions
If you track spend by department or project, map each Weel team to the corresponding DualEntry dimension. Mapped transactions and reimbursements then carry that dimension through onto the posted entry. - A card-payable balance that reconciles
Each charge debits the mapped expense account and credits the Weel card-payable account. Settlement events match posted transactions to the Weel statement, so the payable balance in DualEntry tracks Weel without a manual month-end comparison. - Refunds and edits as adjustments
A refund reverses the original charge against the same accounts, and an edit in Weel comes through as an adjustment instead of a second entry. The DualEntry balance reflects the current state of the transaction, not its first version. - Reimbursements alongside card spend
Approved employee expenses post as expense entries attributed to the cardholder and the budget they were drawn against, and carry through to your AP and GL workflows the same way a manually entered card expense would. - Exceptions you can see
Unmapped categories, amount or tax mismatches, and failed postings are all surfaced through the APIWorx portal and logged with the Weel transaction ID. A GST figure that does not match the mapped treatment raises an exception rather than posting something that would not reconcile, and transient failures retry automatically. - How the connection is made
Setup authorizes APIWorx against your Weel organization for read access to card transactions and expenses, and against your DualEntry company. APIWorx maintains and monitors the connector on its own infrastructure and retains the logs for troubleshooting and audit.
FAQ
Yes. The connection is delivered by APIWorx, a managed integration platform that sits between Weel and DualEntry and runs the connector as a managed service on its own infrastructure, with continuous monitoring and logging.
There is no Weel connector tile inside the DualEntry application. Your Weel organization and your DualEntry company are each authorized to APIWorx during setup, and mapping and sync settings are maintained through the APIWorx portal rather than in DualEntry.
Weel card spend and approved reimbursements arrive in DualEntry already coded to the GL account you mapped, with the GST amount and rate on a separate tax line and the cardholder, team and budget carried through onto the entry. Nobody exports a transaction list and recodes it by hand.
Because each posted transaction is matched to the Weel card statement at settlement, your card-payable balance in DualEntry reconciles to Weel rather than being rebuilt from scratch at month end.
No. The flow is inbound only: Weel spend moves into DualEntry, and DualEntry does not push your chart of accounts or journal entries back to Weel.
That means Weel stays the source of truth for the transaction, cardholder, budget and GST, while DualEntry owns the chart of accounts, tax treatments and posted ledger. When you add a GL account in DualEntry or restructure budgets in Weel, update the corresponding mapping in APIWorx yourself, because the chart of accounts does not sync automatically.
Weel is an Australian platform and most transactions include GST, so the connector reads the GST amount and rate on the transaction and posts a matching tax line in DualEntry. The GL account mapped to the category receives the net expense and the mapped tax treatment receives the tax, so GST is never rolled into the expense figure.
Your DualEntry tax treatments need to be configured before mapping begins. If a transaction's GST does not match what the mapped treatment expects, the connector raises a tax mismatch exception rather than posting a figure that would not reconcile.
Transactions sync near real time on Weel events where webhooks are available, and on a configurable batch schedule otherwise. You choose the sync mode during setup.
A new or settled card transaction, or an approved expense in Weel, triggers the sync: APIWorx retrieves the record, applies your mappings, and posts the result to DualEntry.
The connector does not fail silently. Every exception is surfaced through the APIWorx portal and logged with the Weel transaction ID, across three cases: an unmapped category, an amount or tax mismatch against the Weel statement, and a failed posting to DualEntry.
Transient failures retry automatically, so a record in the error list is not necessarily lost. Check whether the connector has already retried and cleared it before reprocessing manually. APIWorx retains these logs for troubleshooting and audit.
.avif)