Application layer without domain logic?

Hi all,

I am currently planning a new billing system for one of our customers.  A few operational systems are going to
user the billing system as a service. When booking a transaction, the operational system must pass the
customer account (an identifier) to be billed, a product (an identifier) and a few more infos. The product
price is based on the customer account and the product so it can be fetched internally.

Now so far I planned to have the following entities:
- Customer Account
- Product
- Price List
- Accounting Record

When booking a transaction a customer account will be debitted. But there can be several cases, that when an
operational system is booking a transaction there is no customer account because the wrong identifier
might have been provided. In this case the transaction needs to be marked as invalid, needs to be stored and
later on repaired by one of the employees by providing the correct information (like an existing customer).

The decisions whether to create and store an invalid transaction record or to store a valid accounting
record are, from my point of view domain logic.

So I was thinking about creating a service that will take care of the above issues like:

BookTransaction(customerId, productId, ...)
{
   customer = repository.find(customerId);
   product = repository.find(productId);
   if(customer == null || product == null)
     // store as invalid transaction
   else
     // store accounting record
}

Now my question is if it is correct to have a service that books transactions and decides whether a
transaction is valid or not and takes the appropriate actions? Would this service be an application or a
domain service (in the same a assembly as the domain model)? 

Thanks in advance,
Chris

------------------------------------