How to find which account (RECEIVABLE_INVOICE) corresponds to Invoice
Milan
Member Posts: 14
Hi I am trying to create a transaction to mark one of the invoices paid using "Money in Transit" account.
I noticed that there is one RECEIVABLE_INVOICE
account for each Invoice created.
I have managed to create the transaction where my anchor account is money in transit account and line item account is RECEIVABLE_INVOICES
account.
Is this a right way to do this? If so, how to identify RECEIVABLE_INVOICES
account for the invoice I want to mark paid?
Thank you, Milan
Tagged:
0
Comments
is anyone able to answer this @PaulC ?
Hey @Milan
My apologies if I'm a bit confused as to what it is you're trying to bookkeep here. But I wanted to address a few points that I may need some more clarity on:
Typically there should only be one accounts receivable for your invoices created. Can you send a screenshot of the multiple AR accounts you're seeing? This is not usual behaviour.
It sounds like you might be trying to bookkeep for undeposited checks that haven't yet cleared. If so check out this article.
https://support.waveapps.com/hc/en-us/articles/360000389783-Bookkeeping-undeposited-checks
Also I noticed you posted this in the API thread. Is this in regards to a specific integration?
Hope this helps but don't hesitate to reach out if you have other questions.
Hi @Barsin ,
Just read that article, and yes in principal it is the same. More specifically in the same way when client pays for an invoice in Wave using Wave and the transaction is created 'between' invoice and 'Money in Transit' account;
I am trying to do the same using API and another payment processor:
When a transaction is initiated using 3rd party payment system I get notification (via email), I am trying to create transaction (in the similar manner as above) 'between' invoice and my custom 'Money in Transit' account (that I've created for this 3rd party payment system.
Now I know how to create a transaction using API where I'd use 'Money in transit' account as anchor account but I am not able to identify correct account (in
lineItems
) so that specific invoice is being marked as payed (check my example at the end)I poked around and found that there are as many account's of subtype
RECEIVABLE_INVOICES
as there are invoices in my system. And when i create a transaction using one of these accounts' ids i got transaction create (similar to the one above). But I can't find a way to 'match' that accountId with invoice I want.Or am I doing this wrong completely?
I am aware that Zappier solves this (is able to identify invoice and create matching transaction) but i am trying to do it using Wave API - which makes me wonder if Zappier integration is using the same API
As for your question:
I executed this query:
and got all these accounts
picking one of these (as I mentioned above) and creating transaction results in correct transaction create in Wave
Example: executed mutation MoneyTransactionCreate using variable:
and got transaction created as I needed:
@Barsin any thoughts on this?
@Barsin Hi I've responded to your question on Aug 21 - and haven't heard back from you?!?!
Hi @Milan,
Thanks for your patience on this.
Unfortunately, I don't have a solution for you on matching AR accounts to Invoices. Frankly, this is not the 'intended' way for external users to record invoice payments, and very likely these special-purpose accounts will become hidden from the API going forward.
I can advise the team is working on a specific Invoice Payment endpoint, that will be the correct and supported approach for recording invoice payments.
With the above caveats, if you really want to figure this out, the only suggestion I have is to start from zero unpaid invoices, and build your workflows so that each time you create / approve an invoice, you then get Accounts and identify the newly created account. This does, of course, mean you need to maintain a list of Accounts in your connected solution. Also, please note that creation of the AR Account may not be instantaneous with creation of the invoice, so you need to accomodate a little latency.
Hope that helps.
Thanks Paul - this sounds like a feasible workaround. hmmm challange !