Hi Jeroen,
I generally advise against optimising scenarios for reuse. It's good to evolve a consistent domain model/language, and that will lead to some common scenario blocks useful in various places, but doing a scenario in a particular way just because it's easier to reuse steps is generally a bad idea. This is because you start describing how something is tested instead of what's being tested, and six months down the line it becomes a maintenance nightmare.
separating "what" and "how" is one of the key success patterns for scenarios in tools like specflow. push reuse one or two levels below (fixture code implementing the steps, classes that that code reuses). this gives you compile time support for refactoring, intellisense and a lot more.
going back to your particular example, "The name, administration and status is maybe not relevant in above example." - so what is? what makes one expense bundle the same as the other? point that out to make it clear. that's one of the benefits of using a text layer on top of code, to make important things really clear. then show with some boundary examples what is OK or not OK.
eg what if Tommy tries declaring expenses for trip to new york; what if tommy declares it but for a different date? how different does the date need to be? what if lucy declares it on a different date. what if it's a different name but same date/company.