*laughs* ref($cargocult) || $cargocult; Very nice! :-)

Otherwise, it all looks fine. You've got a lot of the idioms I would use in an OO situation.

A few ideas to bring (and boggle) you further:

1. Use closures to generate the accessors in Expense.

   sub new {
       # Stuff up here
       foreach my $attrib (keys %$self) {
           my $conv_attrib = $attrib;
           $conv_attrib =~ s/^_(\w+)$/lc $1/e;
   
           no strict 'refs';
           *{__PACKAGE__ . "::$conv_attrib"} = gen_closure($attrib);
       }
       return $self;
   }
   
   sub gen_closure {
       my $attrib = shift;
   
       return sub {
          my $self = shift;
          if (@_) { $self->{$attrib} = shift; }
          return $self->{$attrib};
      }
   }
   [download]

   That is much easier to maintain when you start hitting 20 or 30 attributes in your objects.
2. Look at separating your database logic from your business logic. This is something we're hitting where I work right now. It'll sound crazy, but if this is going to scale, you will need to do that. Maybe something along the lines of DB::Expense so that if your database schema changes (which it will), you aren't left scrambling to fix your beautiful OO structures.

Good luck!

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.