With preemptive strike i.e. use of Win32::LongPath and switching of the default to ensure proper Unicode handling if paths use characters outside your ANSI codepage:

use Win32::LongPath 'getcwdL';
use File::Spec::Functions 'catfile';

use Win32::OLE;
Win32::OLE-> Option( CP => Win32::OLE::CP_UTF8 );
# ...

$pathfile3 = catfile( getcwdL, 'Template', "$input.xlsx");
$Book2-> SaveAs( $pathfile3 );
[download]

Edit. It occurred to me, you may want to run the script while in another directory:

use FindBin;
use File::Spec::Functions 'catfile';

use Win32::OLE;
Win32::OLE-> Option( CP => Win32::OLE::CP_UTF8 );
# ...

$pathfile3 = catfile( $FindBin::Bin, 'Template', "$input.xlsx");
$Book2-> SaveAs( $pathfile3 );
[download]

There is a regression above, in that I don't assume you plan to work with non-ascii file paths (while, still, it's OK to pass Unicode strings to Excel - which I think is not uncommon even for ascii-people). The reason is there seem to be ugly details not covered by Win32::LongPath or other modules I know -- both $0 and $FindBin::Bin contain encoded (ANSI-CP) strings, so there is a mess not only with decoding, but testing what happens if path to perl script has non-ANSI-CP characters in relative path.