Is there a common supertype (parent class) for a 'receipt' type (class) and an 'invoice' type (class)? It should be possible to state "an instance of receipt/invoice is a supertype."
5 Answers
I think the least ambiguous term that could encompass both an invoice and a reciept would be bill. This is what I would recommend if you wanted an informal description. Some of the accounting and legal terms suggested by others might be better if your target audience is accountants and lawyers. If you're looking for a good class name that will mostly be consumed by programmers, then I would stick with "bill".
answered Nov 8, 2011 at 11:38
-
Thanks. Unfortunately you guessed correctly regarding my target audience, as requirements, specifications, and design documents must be primarily handled by business people, accountants, and lawyers, and 'bill' or 'billing' is mostly used for what is presented to a customer before payments or proofs of purchase are issued. Commented Nov 8, 2011 at 14:51
-
"Bill" is often used to indicate a statement of what is expected to be paid i.e., it can preceed payment. This is the sense in which "invoice" is typically used. However, "bill" is also frequently used to indicate what has been paid, which is the sense most strongly implied by "receipt". Therefore "bill" could apply pretty well to both sub-types and benefits from being both broadly understood and succinct - both of which are good qualities for a class name. Commented Nov 8, 2011 at 14:58
-
I agree that 'bill' is an acceptable abstraction, however, given the context within which 'receipt' and 'invoice' would typically exist (a commerce application with numerous other financial constructs), wouldn't 'bill' or 'billing' be more suitable to what is presented prior to payment and invoicing? If not, then we would have to use 'order summary' to denote the role of what would more naturally be called 'bill'; but then, an actual summary of an order, which culminates in its billing aspect, would need renaming. Commented Nov 8, 2011 at 15:12
Source document is one term that's used in accounting: http://en.wikipedia.org/wiki/Category:Accounting_source_documents
-
'Source Document' seems slightly vague, and will more than likely result in ambiguity in the system, since many of the things which could be 'Source Documents' are also in the system (as concepts, labels, class names, and so on). Commented Nov 7, 2011 at 18:39
Maybe Billing Statement or Financial Statement? I've never heard a single word that fits exactly what you want, but maybe these two options are pretty close?
answered Nov 7, 2011 at 18:17
FrustratedWithFormsDesignerFrustratedWithFormsDesigner
7,1481 gold badge27 silver badges38 bronze badges
-
Perhaps 'Billing Statement' refers more to the intent of billing a customer, for example at the end of an order summary, rather than a proof of payment or promise of future payment along with tax and legal information? 'Financial Statement' seems too vague, although it is acceptable. Commented Nov 7, 2011 at 18:23
-
@Alexis Petrounias:
Billing Statementcould refer to a receipt since a receipt is a statement proving that an invoice has been paid off, butBilling-related statement(which I think would technically fit a bit better) is a little long, IMO. I agree thatFinancial Statementcould be a too broad in that it would cover invoices, receipts, but probably other documents as well (such as account balance statements). Commented Nov 7, 2011 at 18:26 -
Agreed. In the system I am designing, a 'Billing' construct contains a 'Payment' construct as well as an 'Invoice/Receipt/etc.' construct; hence my need for a short descriptive abstraction. Commented Nov 7, 2011 at 18:38
The word voucher is used as an official legal/accounting translation of such an abstract term from Greek παραστατικό.
Merriam-Webster contains the following compatible definition 2.b: "a documentary record of a business transaction", as well as an incompatible definition 2.d: "a form or check indicating a credit against future purchases or expenditures" which semantically fits more with Wikipedia's definition: "A voucher is a bond which is worth a certain monetary value and which may be spent only for specific reasons or on specific goods."
However, under Accounts Payable, the Wikipedia article also gives the following definition: "A voucher is an accounting document representing an internal intent to make a payment to an external entity, such as a vendor or service provider."
When I take off my native English speaker hat and put on my software developer hat, it occurs to me that there is another way to answer this question - so I will add a separate answer to keep each point of view distinct.
In any accounts receivable / cash application app that I've ever worked on, it became abundantly obvious to me that there is not necessarily any strict correlation between what a customer is expected to pay (invoices) and what they actually pay at any given time (receipts). In many cases, these things don't even agree over time and you have to add adjustments (like credit notes or write-downs) to zero out a customer's account.
Therefore, instead of thinking about a word which has a meaning that can encompass both invoices and receipts, I think the best answer for Alexis' situation is to find a more broadly defined business object that includes both the expectation of payment and the payment actually received.
For this purpose, I would suggest the term: receivable.
Your invoices are statements of the expected amounts that are receivable and your receipts are statements of the actual amounts that are receivable. Maybe that is the best way to name your super-type?
answered Nov 8, 2011 at 15:16
-
This is very interesting. It also applies to my own answer above with the word 'voucher' which seems to mean both a record of a transaction which has gone through, as well as a promise to complete a transaction in the future. I agree with you that, since the operators of financial aspects of such a system are accounting/financial people, their expectations - from a design point of view - should take priority. Commented Nov 8, 2011 at 15:25