Advanced reporting feature for accounting

[NicolasDorier]

For a while, I wanted to improve the reporting aspect of BTCPay for accounting purpose, but had no clear idea on how we would manage it, so I was waiting inputs from heavy users feedback.

While our CSV export of invoice is great, it only includes deposits.

I recently got the following feedback from an heavy user.

@astupidmoose since you are big user, maybe you have additional feedback.

---

For accounting, it would be better if users can also have a "transaction report" aside from the invoice export which is limited to deposits.

I have made a mock up below on how it should look and function (just a suggestion)

<-Own report section->
Filter on top

1. Date
2. Crypto type
3. Fiat type

Quick report after filter
1.Total deposits
2.Total withdrawals
3.Total transactions
4.Total mining fees paid
5. Successful transactions (Paid Invoices, Paid Over Invoices)
6. Failed transaction (Invalid Invoices, Paid Late Invoices, Paid Partial Invoices)

Graph

1. Graph comparing previous days upto current date sales.

Report section

1. Quick summary for the selected date(s).

It will be helpful for the users if they have their own report section where they can monitor all the details of in and out transactions including mining fees paid in one page.

[NicolasDorier]

Some question I have: Why Failed invoice is important?

[NicolasDorier]

What if a paid invoice become later invalid because it has not been confirmed on time? Why don't you rather use confirmed/completed ?

[lucidddreams]

Why Failed invoice is important?
-Having a report on failed transaction would give an idea to the user on actions to be taken care of, for example a user saw 5 failed transactions in a day report > user will then check the (paid late/partially paid) in that date and contact the payer for necessary action.
Sample use cases/actions
Paid Late Invoices -Need to complete the transaction manually (manual mark as complete)
Paid Partial Invoices - Contact user to send additional lacking payment

What if a paid invoice become later invalid because it has not been confirmed on time? Why don't you rather use confirmed/completed ?
Paid invoice that later become invalid will just be reported as Failed transaction -usually this transactions do not need additional actions from BTCpayserver user and occasionally occurs.

1. Completed/confirmed deposits can be reported as Succesful number of transactions
2. Failed & Expired can have its own count too
3. Paid Late Invoices, Paid Partial Invoices will also have separate count

All of these are suggestions only.

[Kukks]

In a previous project I worked on, the best way to cater for all reporting demands was to add specific database views (transactions, invoices) and attach OData to those views. Then, provide an OData UI to the end user and they can query to their hearts content. This can also be used to pave the way for the dashboard feature that @pavlenex has mentioned multiple times

…

On Wed, 9 Jun 2021, 06:47 VcashPay, ***@***.***> wrote: Why Failed invoice is important? -Having a report on failed transaction would give an idea to the user on actions to be taken care of, for example a user saw 5 failed transactions in a day report > user will then check the (paid late/partially paid) in that date and contact the payer for necessary action. Sample use cases/actions Paid Late Invoices -Need to complete the transaction manually (manual mark as complete) Paid Partial Invoices - Contact user to send additional lacking payment What if a paid invoice become later invalid because it has not been confirmed on time? Why don't you rather use confirmed/completed ? Paid invoice that later become invalid will just be reported as Failed transaction -usually this transactions do not need additional actions from BTCpayserver user and occasionally occurs. 1. Completed/confirmed deposits can be reported as Succesful number of transactions 2. Failed & Expired can have its own count too 3. Paid Late Invoices, Paid Partial Invoices will also have separate count All of these are suggestions only. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2561 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN357VQLW6NZEFQ5JHX663TR3W6HANCNFSM46LCJY2Q> .

[NicolasDorier]

Dashboard is different from accounting reporting, the first is to give high level view to the manager of latest changes.

Reporting for accounting is just a way to export data monthly or so to your accountant so he can reconcile more easily where the money is going.

[NicolasDorier]

I think in the reporting case, separate views / materialized views / separate table via some ETL process.

Then we could expose those table to some proper tooling that may even be not provided by BTCPay at all, but with a separate stack to add with opt-add-.

Just brainstorming here: I think firefly already have some capabilities concerning reporting and querying. Why not just integrating with fireflii directly? (and you already part of the work btcpayserver/btcpayserver-docker#344)

[NicolasDorier]

Look at those beauty:

https://docs.firefly-iii.org/firefly-iii/advanced-concepts/reports/

[Kukks]

Imo there shouldn't be a distinction. Both need access to potentially the same dataset. Allowing the user to create their own dashboard using a flexible data source means they can customize it to their needs, being accounting or for a quick glance

…

On Wed, 9 Jun 2021, 07:10 Nicolas Dorier, ***@***.***> wrote: Dashboard is different from accounting reporting, the first is to give high level view to the manager of latest changes. Reporting for accounting is just a way to export data monthly or so to your accountant so he can reconcile more easily where the money is going. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2561 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN357TCO5YGXWCW4ZOBHODTR3ZVLANCNFSM46LCJY2Q> .

[pavlenex]

I agree there shouldn't be a distintion.

[woutersamaey]

Another solution may be sending the data to Google Data Studio, as this tool allows for easy visualization and dashboarding. Agree, you’d be sending data to Google, which may not be your thing.

[Zaxounette]

We make it so that the very minimum of informations are sent outside of the stack.
We even refactored the default POS app images so they get stored locally instead of pulling them from another website.

Hard NACK on this.

[woutersamaey]

Don't get me wrong. I totally agree.

[mchapiro1]

I was drafting this exact same feature request, including a screenshot from WooCommerce as an example.

Simplest thing to start that I want to be able to see: total btc inbound (on-chain + LN) by month.

I just want to be able to see this at a glance, without having to export data.