layout for invoices and related payments in a B2B billing statement

Question

In a B2B billing statement, what's a clear way to illustrate the many-to-many relationship between invoices and payments?

Here's more background:

Our B2B web app helps companies manage sales and deliveries of food to other businesses. Currently our app prints invoices (as PDFs) but doesn't have a way to roll up multiple invoices to give a customer the current state the account. So we're adding a "billing statement" feature to allow our customers to more clearly to communicate to their customers the current state of accounts-- and to provide a reminder for their customers to pay their bills!

The basic requirements are these:

• Show a list of all unpaid invoices plus any paid invoices during the time period covered by the statement (e.g. one month)
• Show payments that correspond to those invoices in a way that makes it really obvious which payment corresponds to which invoice.
• Show all "open payments" meaning payments that have been received but that have not yet been mapped to an invoice.
• Support many-to-many mapping between payments and invoices: a single payment can be split between invoices and/or an invoice can be paid using multiple payments.

All the Googling I've found lots of billing statement examples but all are "consumer-style" statements that simply show transactions and payments chronologically. I have yet to find an example online of a B2B-style invoice that clearly associates invoices with payments or shows how to show a payment that's split across multiple invoices.

I'm sure I'm not the first person who's tried to build a B2B billing statement. Is there a best practice UX for this kind of "list of invoices and related payments" table? Is there an app (desktop or web) that does a good job at this kinds of invoice UX?

Answer 1

Here's what I understand from your question:

• For your customer, you want to produce statements that they can give to their clients, so the client can tell the state of their account.
• You don't want to re-invent the wheel, but you're not finding any models (statements) to start from.

And I can see there's potential complexity that needs to be communicated simply and clearly in these statements. A client may make multiple payments per month, and a payment may be applied to multiple invoices. I imagine there are returns, price adjustments, short-shipped orders (1 case instead of 2), product substitutions (Dole bananas instead of Chiquita bananas), and so on.

This is a very interesting business problem. You've identified the basic requirements, and you probably know many of the variations/complications in this scenario.

In you position, I would set aside the online research efforts (Google, StackExchange) for now, and take a hands-on approach, because of the potential payoff:

• Conduct some user research. For this, you need a UX researcher. Have you observed your customers as they handle inquiries and receivables? How do they currently explain things to their clients? Where are the pain points? What is commonly misunderstood? Have you asked your customers how they imagine this statement could look? How it mustn't look?
• Develop a few possible solutions. For this, you need an information designer. What options are there to design the presentation of information so it is understandable?
• Then it's time for some formative testing, to shape the design. How do the design options perform? where are the pain points? Do the designs support your customers' business drivers as well as meet the needs of their clients?

It's possible to find a skilled UX person who can do the research, the information design, and the testing. I recommend you hire someone to help you get past these immediate obstacles, so you can develop a great solution for your customers and their clients.

Good luck with what sounds like a fun business problem! I hope my response is helpful.

Answer 2

Unfortunately I cannot recreate use cases laying in the basement of your requirements. I believe if you could describe the task in terms of user's goals in different circumstances it would make discussion more productive.

For now I can only suggest to give up on many-to-many relationship mapping as potentially very confusing and create separate views with payments and invoices as root category for each of these views.