## 6 Feasibility Study
### Issuing and Paying an Invoice  
This Section covers the scenarios for testing the feasibility of issuing and paying invoices with VAT split payments within MTS. These scenarios cover the cases where an invoice is being paid by an account which has or has not sufficient funds to cover the total value of the goods purchased. In this test (see Algorithm A1), a payment is created when a seller (MegaCompany) issues an invoice to a buyer (Alice) (see row 8 in Algorithm A1). This invoice contains information which is found in a regular invoice, such as the class of goods purchased, the quantity of items per class, the net price, the VAT rate for each class of goods, and the total price for the invoice. In addition, each invoice contains the type of money that will be used for the payment, which can be one of two types: Current and Token. If the type is Current, then the invoice can only be paid with funds from [PERSON]' account. This is because certain item classes (e.g., alcohol) do not belong in the allowed goods (see Algorithm A1). For a complete list of fields, see the invoice state constructor in Figure 3.  
After the invoice is issued, it is appended in the unpaid invoice queue for both Alice and MegaCompany. HMRC, via its _VATPayments_ account, should not have visibility of any unpaid invoices; therefore, is not aware of the transaction between Alice and MegaCompany. The first assertion test (AT1) verifies that the (yet unpaid) transaction is only visible by the accounts Alice and MegaCompany (see rows 9-12 in Algorithm A1). The invoice is paid by Alice, which is followed by the next assertion test (AT2) which verifies that all counterparties see the invoice as paid (rows 14-17 in Algorithm A1). The final assertion test (AT3), verifies that all account balances are now updated according to the transactions (payment for goods and VAT split payments; see rows 18-21 in Algorithm A1). A subsequent test (see Algorithm A2) was conducted to verify that a transaction cannot be completed if Alice does not have sufficient funds in their account to pay for the invoice's total amount. In this case, the unpaid invoice is created first, and the payment fails with an error \"insufficient funds available\" when Alice tries to pay for the invoice. The invoice, according to Assertion Test 4 (AT4), must remain in the unpaid state (see rows 10-13 in Algorithm A2). The account balances for all counterparties should also remain unchanged (see rows 14-17 in Algorithm A2), which is verified by Assertion Test 5 (AT5). The next series of assertion tests (as listed in Table 5) were conducted to verify that goods can be purchased by spending tokens. In this test, a different shopping list was used (see Algorithm A3), where only goods from the allowed goods list were to be purchased. According to the Assertion Test (AT6), the invoice state must change to paid (see Algorithm A3 rows 10-13). Assertion Test 7 (AT7) was conducted to check whether the balances were correct after the tokens were spent (see Algorithm A3 rows 14-17). One more test (see Algorithm A3) was conducted to verify that a transaction cannot be completed if [PERSON] pays for goods that are not in the allowed goods list, e.g., alcohol, with money from their token account (see Figure A1 for the shopping list). In this case, the payment for the invoice fails with the error \"you cannot pay for invalid goods with money from your token account\". The invoice remains in the unpaid state (see rows 10-13 in Algorithm A4). The account balances for all counterparties should also remain unchanged (see rows 14-17 in Algorithm A4). The assertion tests returned positive results for all the test cases, thereby proving that the split VAT payment functionality is feasible with the MTS use case for the Smart Money system. This has been found to work properly for variable VAT rates in the same invoice, e.g., an invoice with goods of all three VAT rates (0%, 5%, and 20%).