Bug/ap ar account fanout - #220
Merged
Merged
Conversation
* Bug fix - multiple accounts payable
Bug: payable_account_id is dropped in stg_quickbooks__bill_payment, causing data fanout in int_quickbooks__bill_payment_double_entry when more than one account shares account_type = 'Accounts Payable'
Package
fivetran/dbt_quickbooks (also present in the deprecated fivetran/dbt_quickbooks_source)
Summary
int_quickbooks__bill_payment_double_entry.sql posts the debit side of every Bill Payment to every account whose account_type = 'Accounts Payable', instead of to the one specific AP account each payment actually clears. This silently multiplies real accounts-payable activity onto any other account in the chart of accounts that happens to share that account_type — which QuickBooks allows, even though it isn't the intended one-AP-account-per-currency design the package assumes.
The root cause is that the source bill_payment object does carry a payable_account_id field (confirmed present in the raw Fivetran-synced bill_payment table), but stg_quickbooks__bill_payment.sql never selects it through to the staging layer. Because that field isn't available downstream, int_quickbooks__bill_payment_double_entry.sql has no way to join precisely, and falls back to matching by account_type + currency_id alone.
This is inconsistent with int_quickbooks__bill_double_entry.sql, which handles the equivalent case correctly by using bills.payable_account_id directly for its credit-side entry — that model is not affected by this bug.
Where the bug is
models/staging/stg_quickbooks__bill_payment.sql — final select omits payable_account_id even though it exists on the source table:
final as (
select
cast(id as {{ dbt.type_string() }}) as bill_payment_id,
cast(check_bank_account_id as {{ dbt.type_string() }}) as check_bank_account_id,
check_print_status,
cast(credit_card_account_id as {{ dbt.type_string() }}) as credit_card_account_id,
exchange_rate,
currency_id,
cast(department_id as {{ dbt.type_string() }}) as department_id,
pay_type,
total_amount,
cast( {{ dbt.date_trunc('day', 'transaction_date') }} as date) as transaction_date,
cast(vendor_id as {{ dbt.type_string() }}) as vendor_id,
created_at,
updated_at,
_fivetran_deleted,
source_relation
from fields
)
models/double_entry_transactions/int_quickbooks__bill_payment_double_entry.sql — because payable_account_id isn't available, the join falls back to matching every account of the configured account_type:
ap_accounts as (
select
account_id,
currency_id,
source_relation
from accounts
where account_type = '{{ var('quickbooks__accounts_payable_reference', 'Accounts Payable') }}'
and is_active
and not is_sub_account
),
bill_payment_join as (
select
...
coalesce(bill_payments.credit_card_account_id, bill_payments.check_bank_account_id) as payment_account_id,
ap_accounts.account_id,
...
from bill_payments
left join ap_accounts
on ap_accounts.currency_id = bill_payments.currency_id
and ap_accounts.source_relation = bill_payments.source_relation
),
Since the join only matches on currency_id + source_relation, every Bill Payment fans out into one debit row per matching AP-type account, not one debit row for the specific account it actually pays down.
The DECISIONLOG does document that a single AP account per currency is a requirement and that multiple AP-typed accounts cause fanout, but since payable_account_id is already present on the source object, this looks like an unintentional oversight rather than an inherent limitation — the fix is available in the data, it's just not being used.
Reproduction
In a company file with 4 accounts sharing account_type = 'Accounts Payable' (one real "Accounts Payable" control account, plus three other liability-type accounts that were misconfigured with that same account_type in QuickBooks), querying quickbooks__general_ledger shows:
account_id
account_name
debit txn count
debit total
131
Accounts Payable (real)
2,769
$19,734,953.91
211
Loan Payable
2,758
$19,726,244.63
286
Loan Payable-Equipment
2,758
$19,726,244.63
178
Payroll Taxes Pay
2,758
$19,726,244.63
Three unrelated accounts show a nearly identical transaction count and dollar total to the real AP account — because they're all receiving a copy of the same underlying Bill Payment activity. This produced multi-million-dollar phantom balances on quickbooks__balance_sheet for accounts that should be at or near $0.
Impact
Any customer with more than one account carrying account_type = 'Accounts Payable' (which QuickBooks Online permits, even if not best practice) will see their non-AP account(s) silently inflated by the full company-wide AP payment volume, with no error or warning — the totals are close enough to the real AP account's totals that it can look plausible rather than obviously broken.
Suggested fix
Add payable_account_id to the final select in stg_quickbooks__bill_payment.sql:
cast(payable_account_id as {{ dbt.type_string() }}) as payable_account_id,
In int_quickbooks__bill_payment_double_entry.sql, join bill_payment_join to ap_accounts on the specific account instead of (or in addition to) account_type:
left join ap_accounts
on ap_accounts.account_id = bill_payments.payable_account_id
and ap_accounts.source_relation = bill_payments.source_relation
This mirrors how int_quickbooks__bill_double_entry.sql already handles the Bill side correctly via bills.payable_account_id.
Workaround
Until this is fixed upstream, we're overriding both models locally (defining models of the same name in our own dbt project, which take precedence over the installed package version) with the change above. We're also correcting the account_type of the misclassified accounts directly in QuickBooks, since that's the proper long-term fix regardless of this package behavior — but the package should not silently fan out data even when a customer's chart of accounts is misconfigured this way.
* bug fix - multiple accounts payable
Bug: payable_account_id is dropped in stg_quickbooks__bill_payment, causing data fanout in int_quickbooks__bill_payment_double_entry when more than one account shares account_type = 'Accounts Payable'
Package
fivetran/dbt_quickbooks (also present in the deprecated fivetran/dbt_quickbooks_source)
Summary
int_quickbooks__bill_payment_double_entry.sql posts the debit side of every Bill Payment to every account whose account_type = 'Accounts Payable', instead of to the one specific AP account each payment actually clears. This silently multiplies real accounts-payable activity onto any other account in the chart of accounts that happens to share that account_type — which QuickBooks allows, even though it isn't the intended one-AP-account-per-currency design the package assumes.
The root cause is that the source bill_payment object does carry a payable_account_id field (confirmed present in the raw Fivetran-synced bill_payment table), but stg_quickbooks__bill_payment.sql never selects it through to the staging layer. Because that field isn't available downstream, int_quickbooks__bill_payment_double_entry.sql has no way to join precisely, and falls back to matching by account_type + currency_id alone.
This is inconsistent with int_quickbooks__bill_double_entry.sql, which handles the equivalent case correctly by using bills.payable_account_id directly for its credit-side entry — that model is not affected by this bug.
Where the bug is
models/staging/stg_quickbooks__bill_payment.sql — final select omits payable_account_id even though it exists on the source table:
final as (
select
cast(id as {{ dbt.type_string() }}) as bill_payment_id,
cast(check_bank_account_id as {{ dbt.type_string() }}) as check_bank_account_id,
check_print_status,
cast(credit_card_account_id as {{ dbt.type_string() }}) as credit_card_account_id,
exchange_rate,
currency_id,
cast(department_id as {{ dbt.type_string() }}) as department_id,
pay_type,
total_amount,
cast( {{ dbt.date_trunc('day', 'transaction_date') }} as date) as transaction_date,
cast(vendor_id as {{ dbt.type_string() }}) as vendor_id,
created_at,
updated_at,
_fivetran_deleted,
source_relation
from fields
)
models/double_entry_transactions/int_quickbooks__bill_payment_double_entry.sql — because payable_account_id isn't available, the join falls back to matching every account of the configured account_type:
ap_accounts as (
select
account_id,
currency_id,
source_relation
from accounts
where account_type = '{{ var('quickbooks__accounts_payable_reference', 'Accounts Payable') }}'
and is_active
and not is_sub_account
),
bill_payment_join as (
select
...
coalesce(bill_payments.credit_card_account_id, bill_payments.check_bank_account_id) as payment_account_id,
ap_accounts.account_id,
...
from bill_payments
left join ap_accounts
on ap_accounts.currency_id = bill_payments.currency_id
and ap_accounts.source_relation = bill_payments.source_relation
),
Since the join only matches on currency_id + source_relation, every Bill Payment fans out into one debit row per matching AP-type account, not one debit row for the specific account it actually pays down.
The DECISIONLOG does document that a single AP account per currency is a requirement and that multiple AP-typed accounts cause fanout, but since payable_account_id is already present on the source object, this looks like an unintentional oversight rather than an inherent limitation — the fix is available in the data, it's just not being used.
Reproduction
In a company file with 4 accounts sharing account_type = 'Accounts Payable' (one real "Accounts Payable" control account, plus three other liability-type accounts that were misconfigured with that same account_type in QuickBooks), querying quickbooks__general_ledger shows:
account_id
account_name
debit txn count
debit total
131
Accounts Payable (real)
2,769
$19,734,953.91
211
Loan Payable
2,758
$19,726,244.63
286
Loan Payable-Equipment
2,758
$19,726,244.63
178
Payroll Taxes Pay
2,758
$19,726,244.63
Three unrelated accounts show a nearly identical transaction count and dollar total to the real AP account — because they're all receiving a copy of the same underlying Bill Payment activity. This produced multi-million-dollar phantom balances on quickbooks__balance_sheet for accounts that should be at or near $0.
Impact
Any customer with more than one account carrying account_type = 'Accounts Payable' (which QuickBooks Online permits, even if not best practice) will see their non-AP account(s) silently inflated by the full company-wide AP payment volume, with no error or warning — the totals are close enough to the real AP account's totals that it can look plausible rather than obviously broken.
Suggested fix
Add payable_account_id to the final select in stg_quickbooks__bill_payment.sql:
cast(payable_account_id as {{ dbt.type_string() }}) as payable_account_id,
In int_quickbooks__bill_payment_double_entry.sql, join bill_payment_join to ap_accounts on the specific account instead of (or in addition to) account_type:
left join ap_accounts
on ap_accounts.account_id = bill_payments.payable_account_id
and ap_accounts.source_relation = bill_payments.source_relation
This mirrors how int_quickbooks__bill_double_entry.sql already handles the Bill side correctly via bills.payable_account_id.
Workaround
Until this is fixed upstream, we're overriding both models locally (defining models of the same name in our own dbt project, which take precedence over the installed package version) with the change above. We're also correcting the account_type of the misclassified accounts directly in QuickBooks, since that's the proper long-term fix regardless of this package behavior — but the package should not silently fan out data even when a customer's chart of accounts is misconfigured this way.
* Fix join condition for ap_accounts in SQL query
bug in case of multiple accounts payable
* fix/je-ar-lookup * fix cast
The join in #216 matched ap_accounts strictly on payable_account_id, dropping the account_type/currency fallback entirely. Any bill payment without a populated payable_account_id (most historical synced records) lost its AP account_id outright instead of resolving to the single AP account, silently breaking GL entries for the common case. Falls back to the account_type/currency match only when payable_account_id is null, mirroring the AR lookup guard added in #218.
Mirrors the je_ar_lookup added to int_quickbooks__payment_double_entry in #218. A BillPayment's payable_account_id is null when it's cleared against a Journal Entry rather than a Bill; the linked JE usually still carries a line posted to the correct AP account, so resolve it there before falling back to the generic account_type/currency match.
Same fix as payment_line in #218 - the raw column comes through as an integer on some warehouses (e.g. Postgres), while stg_quickbooks__journal_entry_line.journal_entry_id is cast to string. The new je_ap_lookup join in int_quickbooks__bill_payment_double_entry compares the two directly, so the types must match.
Seed additions recreate both scenarios this branch fixes: - a second same-currency Accounts Payable account (20299) and a bill payment resolved via payable_account_id (9002), another with no payable_account_id resolved via a linked journal entry (9004) - a second same-currency Accounts Receivable account (92003) and a payment resolved via a linked journal entry (9002) New integrity tests (tags=fivetran_validations, gated behind fivetran_validation_tests_enabled): - ap_ar_double_entry_no_fanout: whenever a bill payment/payment is resolvable (populated payable_account_id/receivable_account_id, or a linked JE posting to an AP/AR account), asserts exactly one AP/AR row is produced, not one per matching account_type account - ap_ar_double_entry_no_null_account: asserts the AP/AR leg is never dropped (account_id null) for resolvable transactions - the regression introduced by #216's strict id-only join with no fallback
Patch release documenting the JE-based AR/AP account lookup fix for duplicate account fanout in int_quickbooks__payment_double_entry and int_quickbooks__bill_payment_double_entry.
fivetran-avinash
self-requested a review
August 27, 2026 23:34
fivetran-avinash
left a comment
fivetran-avinash
left a comment
Contributor
There was a problem hiding this comment.
Approved for release review!
fivetran-avinash
added
docs:ready
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Overview
Package version introduced in this PR:
This PR addresses the following Issue/Feature(s):
Summary of changes:
Submission Checklist
Changelog